5 ways to think like a cloud architect

5 ways to think like a cloud architect

Summary: Moving to cloud-enabled applications requires a new way of looking at the way applications are built and deployed. Well, not quite so new.


Is enterprise architecture ready for the cloud? Is the cloud ready for EA? Cloud represents a different way of thinking. But we've been here before.

In a new post, Chris Bruzzi and Nick Hamm, both with Appirio, a cloud services provider, share their experiences in cloud application development. They point to the five changes in mindset that needs to take place as application development and deployment evolves to the cloud world.

For architects and developers who have been working within the service-oriented architecture realm, most of these best practices will look terribly familiar. But Bruzzi and Hamm point out that SOA in the past was more constrained, since it typically stopped at the enterprise walls. Now, as more and more of IT gets hooked up into the cloud, it's time to really promote "service-oriented" thinking:

  1. Architect solutions in a componentized way: "Step back and think about the business requirements and then architect a solution of loosely coupled components that address the overall requirements. This takes a bit more work upfront but pays huge dividends later." 
  2. Value application programming interfaces (APIs) over language: A decade ago, IT organizations were either "Java" or ".NET" shops. The cloud abstracts the focus from applications tightly bound to languages and platforms to service delivery, Bruzzi and Hamm say. "As a cloud architect, that means you too have to shift your focus from the technology or language to architecting services and the APIs used to access them."
  3. Drive reuse wherever possible: Components within a cloud design may be already functional and available either within an organization's own library, or from external cloud providers -- such as Salesfroce.com or Amazon Web Services.
  4. Extend your team with crowdsourcing: Look to development communities -- such as CloudSpokes or 99Designs -- for new components. "The benefit of this approach is that you can get a lot of your application built quickly and in parallel since you’re not constrained by your own team’s capacity. You may also be surprised by creative solutions that you wouldn’t have thought of."
  5. Measure your applications: "With cloud solutions, there’s a lot of data available about your application’s configurations, code, quality and more," Bruzzi and Hamm point out. "Some cloud providers collect these benchmarks but not all do, so you may have to do some legwork!"

(Photo: US Bureau of Labor Statistics.)



Topics: Cloud, Enterprise Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • 6. Design it to be managed

    Design the componentry to be managed across all boundaries, measurement is not enough. You will be moving workloads and specific functionality between cloud layers (private, public, etc.) and changing access methodologies so if you don't design each component to be managed at every layer and via all channels, you will break causal chains needed for troubleshooting
    • Thanks...

      ...great observation
  • 0: Release Early, Release Often

    With such a disparate collection of pieces crossing architectural as well as management boundaries, it's going to be impossible to coordinate a single "production" rollout. In fact, such a concept becomes meaningless. Instead, you will be continually rolling out one incremental update here followed by another one there.

    Which poses interesting requirements for forward and backward compatibility of the protocols you use...
  • But wait! There's more...

    Interesting article. I agree with all five points made, but would add a couple more:

    -- Build components to be monitored. You may have the best monitoring infrastructure in the world, but if your components aren't instrumented to expose useful metrics, you're going to be constrained in the effectiveness of your monitoring.

    -- Stop thinking of "applications". The concept of an application is disappearing and is being replaced by "service/component orchestration". If you've built a set of reusable components, then your application basically becomes a script or workflow that strings together a bunch of components to achieve an objective.

    -- Build discoverable components with different service levels. You may find that you have different performance needs for the same function. For example, if you're performing a calculation over a large dataset, it may be useful to have a variety of components with the same interface. Each of these components offers different SLAs. One may provide two decimal points of precision and executes in 30 seconds, another could offer 10 decimal points of precision but takes 30 minutes to execute and costs 1,000 times more. You should be able to use the same orchestration to drive both components - it's simply the meta data (contained in the SLA & advertised in a service directory) that defines which implementation is invoked.
  • job

    i m doing M.TECH IN CLOUD COMPUTING ... i need know about job opportunities
    manikandan a
  • Great Opportunity / Interesting event

    Learn more about “Door Opening” opportunities that can boost the revenue in your pipeline!

    Ask the Expert Event
    October 16th @ 7:00 EST PM
    "Solutions Made Simple” Featuring System X

    (1) Identifying Customer Solution Challenges
    (2) Delivering the right infrastructure for Customers
    (3) New technology benefits from IBM System x
    Dial in : 888-426-6840 Particpant Code: 108 91 227

    Expert: Mike Scalzo- Systems & Technology Marketing Program Manager

    Enroll in Systems Connect today to attend this valuable forum:
    Edina Bacsó