LinkedIn Twitter Facebook
Lean, Kanban, Agile Pairing, TDD (sometimes test after) software architect and programmer. Worked with distributed (called cloud sometimes) computing services since 2007 using phat data (8 billion rows of data on an AVERAGE day, sometimes called big data) and everything from business intelligence to the nitty gritty of array structures inside file based data stores to create caching tiers for custom software needs. Currently pushing for distributed technologies & improving software architecture, better data centers, the best software development practices and keeping everything secure in the financial industry again. To see what I'm up to today, check out my blog at Composite Code.

5 responses to “Cloud Software Architect Necessities”

  1. Mark Griffin

    Adron,
    Some good stuff here, but I am curious about the REST part. I too use REST style architecture but not in all cases. Can you elaborate on why you think the REST architecture is key to cloud computing. The internet or web is always up part doesn’t seem to jive in my mind in context with REST. The internet is always up is because of redundancy in network infrastructure and the redundant routing nature of TCP/IP, nothing to do with REST. Web sites themselves are not always up and URL’s are not always available. I never really thought the Web was a good example of REST style architecture even though it is quoted as such a lot.

    markg

  2. Chuyen

    Adron,
    Really appreciated your paper. REST is king, really? I think REST is mandatory but doesn’t really address cloud big challenges e.g. billing and scale up/down.

    REST doesn’t give any guidelines on how one may architect servers to match demands, furthermore, what server ‘types’ to power on/off according to SLA.

    What do you think ?

    Ch4

  3. Paul

    I read the blog and responses with interest.

    I work for a company which has a traditional client/server premise based product. Its a classic 3-tier design in J2EE. App content delivered in through the browser (thin client), app logic held in an XML repository (configured using desktop installed developer tools), and a zero-business logic session runs with J2EE container to execute the application logic in runtime, in concert with the client. The XML definitions loaded into the session at run time.

    The architecture uses lot of integration techniques to aggregate data in the end-user application.

    Moving this ‘traditional’ application to a cloud architecture is causing masses of internal debate.

    Its worth noting that the application integrates to telephony platforms to deliver a CTI-enabled application. This seems to me, unless you can correct me, to be an area where REST may not help?

    Any high level comments are welcome! :)

    Paul.