Planning Your Cloud Strategy

Planning Your Cloud Strategy

By Special Guest
Selvaratnam Uthaiyashankar
  |  March 02, 2016

The word “cloud” in the technology context first popped up in the April 1994 Wired article on General Magic. Then the term was almost completely forgotten until Amazon started marketing its Elastic Compute Cloud in 2006.

Fast forward to today, where everyone’s talking about the cloud. For ordinary users, it’s the penultimate storage solution. For architects, developers and administrators, it’s the logical successor of all that bulky in-house hardware. For CEOs, it’s one of the greatest cost savings approaches ever.

Still, the benefits of a cloud implementation are only as good as the strategy behind it. Moreover, while every company’s cloud strategy differs—no one size fits all—there are a few important points to consider when planning any strategy.

The API continues to rise
At one time, the open source code base and library were the kings of the hill. More than any thing else, they are instrumental in enabling rapid development. While free and open source software (FOSS) is still around, the software-as-a-service (SaaS (News - Alert)) model is growing in popularity for making many software capabilities directly available as services and APIs.

APIs are like windows into walled gardens; you may not know what proprietary magic is happening in there, but you can still integrate those capabilities into your application nonetheless. When exposing your data and services—either publicly or privately—you also want a degree of control, so that people can build applications and services around what you offer. API management software can facilitate this effort.

However, cloud strategies often demand the ability to connect systems or services to third-party services, and this is where the use of an enterprise service bus (ESB) with connectors comes in. Essentially, the connector is a building block that lets you link the ESB to publicly available services.

Even if you are not ready to expose your own APIs, you may need to take advantage of those provided by others, such as those from Salesforce, JIRA, and Twitter (News - Alert). This is especially true if your customers already consume those services and want to avoid disruption.

You can’t avoid cloud identity
In practical terms, cloud identity encompasses all of the massive online identity schemas in use today. This is particularly true with social networks as people gain an increasing number of social identities. In fact, Gartner predicted that, by the end of 2015, 50 percent of new retail customer identities would be based on social network identities. It’s no surprise then that we’ve become accustomed to seeing a Facebook (News - Alert) (News - Alert) login on almost every app we use now.

You either need to include social identity in your plans, or develop a strategy for working around the obvious potential loss of customers.

When evaluating identity management solutions for your cloud implementation and public identities, look for identity federation functionality that makes it possible to define multiple identity providers, such as Facebook and Google (News - Alert). You should be able to define multiple authenticators and let your users authenticate against these public identities, as well as define provisioning rules in order to create internal identities for these users. By using a single identity management solution that can consume multiple social identities, you can significantly streamline your implementation and ongoing management.

Do more faster
Agile (News - Alert) development is a way of life now, particularly in cloud environments marked by the rapid rollout of incremental releases. You come up with an idea, you put it into production and you move quickly. Applications are increasingly API-driven, with almost all the functionality provided by either public services or services provided within your organizations, eliminating the time to build an app from scratch.

To fully embrace speed, developers need to access more technologies than ever before, database schemas to programming languages. Instead of R, Python or Java, why not all three? It gets the job done faster. Restricting your toolset is like forcing a mechanic to work with one size of wrench; they may get the job done, but it’s not going to be as fast.

Embracing speed also requires application environments that can scale up or down on demand. This includes everything from hardware to flexible application runtimes. Quick release cycles work well with cloud infrastructure that allows people to build, deploy and test an app as fast as possible. If something fails, then it’s back to the drawing board. Docker and Kubernetes are rapidly becoming very useful enablers in these efforts.

Foster self-service and automation
Traditional IT is pretty cumbersome. You request something and then wait for it. Adding a user or a password reset might take an entire day. This isn’t particularly effective, and often leads to frustrated developers building ad-hoc solutions to work around these problems.

The solution? Aim for platforms where people can come and provision and/or build any functions they need rather than bogging down staff with requests. This could be as simple as having automated password management systems or as comprehensive as providing a platform that people can use to create, deploy and manage enterprise apps in the cloud.

Of course, if you’re going to have a lot of people using your facilities, you will have a lot of technology choices to cater to. This is where heterogeneous runtimes and polygot programming models come in.

Needless to say, this platform should also be workflow driven. Often, there are formalized processes behind the task of getting an application, API or function up and running—including approval and policy enforcement, among others. Ideally, the platform will support this process, so people can just focus on creating and implementing their apps.

By addressing these four criteria in your cloud strategy, you will be well positioned to implement a secure cloud-based solution that fosters user adoption, creativity and agility.

Selvaratnam Uthaiyashankar (Shankar) is vice president of engineering at WSO2 ( where he focuses on the company’s platform-as-a-service and enterprise middleware kernel. Shankar is a member of the Apache Software Foundation and a committer on the Axis2/C, Axis2, Rampart/C, and Rampart projects. Shankar is on Twitter at

Edited by Stefania Viscusi