Showing posts with label infrastructure. Show all posts
Showing posts with label infrastructure. Show all posts

Monday, March 21, 2016

Public clouds are transforming as fast as atmospheric clouds



Is your team developing any solutions that are hosted in public clouds? I mean any software that uses AWS or Microsoft Azure as an infrastructure (IaaS) or platform (PaaS) or both. If yes, you have definitely noticed that the pace of changes of AWS and Azure is extremely fast these days.

To see the speed of changes, you can go through the recent announcements lists for both leading public cloud vendors, AWS: https://aws.amazon.com/ru/new/, and Microsoft: https://www.microsoft.com/en-us/server-cloud/roadmap/recently-available.aspx. Such speed is only possible because there are no traditional release cycles, they release several times per month/week; this is DevOps world.

Of course such pace is a very significant factor for those parties who depend on the public clouds (cloud solution providers, independent software vendors, enterprises, etc.). Both leaders, Amazon and Microsoft, are trying as hard as possible to stick to the commitments they give to the partners/customers regarding the direction they move.

Microsoft, being very oriented to enterprise market, is even trying to make its roadmap clear and public, they recently announced the public Azure roadmap: https://blogs.technet.microsoft.com/server-cloud/2015/01/30/increasing-visibility-for-our-customers-announcing-the-cloud-platform-roadmap-site/. You can see the roadmap here: https://www.microsoft.com/en-us/server-cloud/roadmap.

I am not aware of any public roadmap for AWS for the moment. So what is the risk of having your public cloud provider evolving very fast, why is it significant to realize what set of technologies you public cloud will become in 1, 2, 3 year from now?

Of course, the services/APIs you use now, whether this is IaaS of PaaS level, will not become unsupported without any notice (that would threaten your cloud provider business image), however it is very possible the cloud technologies you are investing in right now will be superseded by their successor technologies in some mid-term perspective and there is no guarantee those two will be backward compatible.

Let’s consider an example with Microsoft Azure: there is big movement from IaaS v.1 to IaaS v.2 currently. New approach, called Azure Resource Manager changes the picture a lot: the whole ideology, API, limits, all this changes significantly (for the better). IaaS v.1 and v.2 are co-existing and not compatible, so you have to choose which way to go. It could sound obvious, just select the most recent version, however the v.2 just doesn’t support all of the Azure features yet the v.1 supports, so right now with v.1 you will be limited, but strategically you are winning.

To summarize, since public cloud vendors are moving really fast mostly due to an extremely intense competition and constantly evolving understanding of Cloud Computing, if you are a part (especially a leader) of a team developing for the public cloud, you need to understand the trajectory the vendor’s technologies are moving and to have the strategy for keeping up.

Wednesday, May 27, 2015

Cloud-related projects: when your backend is really based on cloud services?


A person in charge of the project leadership and finally project success should understand the meaning of cloud-based development project, as this is a really big point (although this game changer is already mature enough).

Cloud-as-a-Buzzword


Due to the big hype for the last 5-7 years, we encounter the word "cloud" and projects related to "cloud services" development very often. In fact, big deal of such cloud-based projects are not about cloud at all. 

Sometimes backend is called "cloud services" just for the marketing purposes (yes, cloud is still cool), but this can be also a lack of understanding of what the "real cloud" means. You can meet a lot of developers (even experienced enough) that can say something like "cloud is actually nothing really different from the traditional client/server with backend in some virtualized infrastrucure (or even just Internet)". It is not like this, however.

When you really develop cloud services and the project is about cloud?


First of all, to be clear, by the "cloud services" I mean not the services CSP (Cloud Service Provider, like Amazon Web Services) provides to the consumers, but the services that represent the back-end of the system which really benefits from the cloud-based architecture. 

Does this mean that any services, being deployed to the public cloud (AWS, Microsoft Azure, etc.) or private cloud (based on OpenStack, etc.) are automatically becoming cloud services? Well, no. Only those services that can really use the cloud's nature are cloud services.

What is the cloud? I think NIST (National Institute of Standards and Technology) gives very good definition for this type of the infrastructure. According to this widely accepted definition. these are the essential characteristics of the cloud infrastructure (with my explanations):


  1. On-demand self-service. This means the cloud consumer should be able to perform all cloud provisioning actions without any help from cloud provider. This can be fully automated with different APIs or done manually through "service catalogue" (usually Web-based user interface).
  2. Broad network access. Stays for ability to consume the software services in the cloud using different types of clients through standard platform-independent protocols (it is not about broadband connection).
  3. Resource pooling. This is related to the fact that cloud infrastructure is shared among different "tenants" to optimize the utilization. This makes it efficient and usually is a big supporting point for the switch to the cloud infrastructure.
  4. Rapid elasticity. Truly great ability of the cloud to quickly grow the amount of provisioned resources for "tenants" when needed and to contract them when not needed any more.
  5. Measured service. This means in the cloud all resources are "commodities" that are standardized and consumption is measured (like electricity consumption).


Most significant enablers for the services developers there are "rapid elasticity", "broad network access" and "on-demand self-service", to my mind.

OK, how to use this knowledge?


It is important that the cloud is not just virtualized infrastructure, not just virtual machines, etc. This is highly automated, elastic, controllable, efficient environment that should be employed in a right way to benefit from it.

You'd better ask your System Architect, Lead Developer/Expert or other person in charge of the technical decisions in your team how your backend services are compatible with cloud-deployment scenarios, how they address scaling in the cloud, what are the interfaces to them that enable services consumption, how is cloud-backed automation levereged, and so on. 

Cloud services can make a real difference for the system/product you develop (especially in terms of scalability and automation) if this is really about using the features of the cloud infrastructure.