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:
- 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."
- 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."
- 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.
- 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."
- 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.)
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
6. Design it to be managed
Thanks...
0: Release Early, Release Often
Which poses interesting requirements for forward and backward compatibility of the protocols you use...
But wait! There's 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