As engineers, we have spent the last 5 or 6 years educating the technology community about the cloud and the foundational principles behind the cloud business. We think that the basic knowledge and value of moving to the cloud is well understood by most organizations. The simple notion of on-demand compute, storage, and network is as attractive as the Capital Expenditures (CAPEX) to Operational Expenditures (OPEX) model for cost restructuring to many businesses.
We believe we are on the right track to address security and specifically, data protection issues with the cloud. We also have a reasonable solution to address on-premises connectivity needs for those organizations that would not move certain segments of their applications and processing to the cloud.
These advances move the technology to the later part of the cloud maturity model. Now that the hype related to the cloud is on the decline, we as engineering leaders must define, implement, and deliver true value to the business.
After working with the cloud for several years, and having previously worked within the large-scale, highly reliable services industry, my experience has allowed me to gain a unique perspective in this regard. Let me share this perspective and share my thoughts on where we should concentrate on the next iteration of innovation.
This perspective can be summarized under three critical aspects of cloud:
- Agility in delivery: Ultra-fast iteration and unprecedented reduction in time-to-market.
- Elasticity in runtime resource allocation: Completely on-demand resource allocation-auto-scaling.
- Commoditization of all runtime resources and services: Commoditize the service, not just foundational resources.
Let us drill down on each of the above aspects and see how that will allow the business value to be realized.
Agility in product delivery
The cloud should provide acceleration to product development and delivery. We technology leaders should watch out for this single metric carefully.
Continuous Integration is a given in modern development cycles. As the code gets written, it is pushed into the build system, then goes to automated testing, moves to system testing, and is delivered to a test environment for further qualification.
But this is not enough.
Cloud can produce another very critical feature. We can create, configure, and run the newly developed software at seconds notice. So we should build and test the changes as they are pushed to source code repositories without any delays. This can produce agility with the least risk of product instability. The point is to continuously deliver the changes to a fully configured environment and have the services in runtime mode all the time in system tests.
But this is not enough today. We should also be able to modify and enrich the product itself continuously. The cloud allows another extremely important feature: Development teams can create product-like environments at a moment’s notice, then use those and tear down the services once they are done.
That means the product development can work on features, which can be validated under real scenarios, reducing the risk of environmental variations.
This is where continuous delivery comes in. Today, most popular services delivery changes daily. The way they achieve that is to have a very streamlined deployment infrastructure.
But for most businesses, similar services can be developed at a fraction of the cost with the cloud. All cloud services provide a rich set of APIs. Many tool chains automate the configuration deployments. Chef, Puppet, Ansible, and many other platforms allow an unprecedented level of sophistication. We are talking about reducing product delivery cycles from several months to a few days using these technologies.
This should result in “Idea-Product-Solution” cycles that iterate in days.
Elasticity in runtime resource allocation
We are at end of capacity planning as we know it. Capacity planning actually never worked.
How do we do effective capacity planning when we need several CPU cores at the end of the month and during the remaining month the machines are used only for reporting no load? Where is the capacity planning in which 80% of the system is used only during the end of the year purchases cycle of e-commerce? For the remaining part of the year, system utilization goes to 20% overall.
In such real-life scenarios, there is no value to capacity planning. The seasonal peaks are so tall as compared to the baseline that CAPEX is making many businesses unviable.
The only solution is to dynamically and aggressively pursue elasticity.
Start with a services layer built for horizontal scaling. Allow the services to scale horizontally as demand grows. Drop the resources and return to unallocated pool aggressively. The important point in the service design is to build systems that allow capacity of the resources to be dynamically changed. We see many systems not capable of utilizing newly added resources dynamically. Many such systems need restart and some intervention. This is not the correct design for delivering services in the cloud.
Technology leaders and operational leaders are underestimating the cost of unused resources in data centers. There is no real solution to this unless we build elasticity in the core of the service architectures. Now, building the systems to use elasticity and dynamically scale services as load changes should be the fundamental feature of every product based on services in the cloud.
There are other aspects of elasticity, which are playing significant roles in modern services and enhancing the effects of agility discussed above. When we combine elasticity with agility, we have a possibility of complete and end-to-end validation of scaling of the service during development cycles at virtually no cost. Before the days of cloud with elasticity, there was no way to see how the software and components would work on large scales. Before the elastic clouds, the only way to test scale was to commit to a CAPEX at the scale. This is unfortunately financially unviable.
But with elastic cloud, the development team can easily create a cloud of 1000 servers, test the services under a large load, validate the results for several days, and tear down the environment there after. The cost of such experiment is well within the reach of moderate sized businesses.
This opportunity is a significant improvement over the past iterations of services.
One more aspect, sometimes mistakenly considered as optional, is critical to the success of any elasticity of the cloud: the complete end-to-end and live service behavior metrics collection.
Any modern service wanting to optimize for cost and elasticity must collect all levels of resource and functional metrics. This includes CPU, Mem, network bandwidth, storage, and layer with every user action and application flow.
The metrics collection of such nature cannot create silos of data. The metrics collection must provide customer use to resource use in an integrated view.
Without this foundational metrics collection, there is no way to optimize and provide dynamic feedback for resource allocation.
Commoditization of resources and services
Cloud model has commoditized the compute, storage, and network.
The services based on such commoditized infrastructure will allow the benefits of low cost and better reliability to be passed on to the solutions only if the above two principles of agility and elasticity are built into the services.
But then the benefits of such cost structures are not fully realized until the services built on top of the infrastructure are commoditized.
One way to bring this feature is to build micro services. The architecture of micro-services does add overhead of service-to-service communication. It does add complexity and additional operational burden.
But the benefits are to commoditize the services to bring down the cost of overall service even further. The way to look at these micro-services is to decide what are the fundamental building blocks of overall service. If we can move away from compute, storage, and network as building blocks to service A, service B, etc., then the service model can evolve much faster.
I see this evolution already taking shape in the form of machine learning-as-a-service, Spark-as-a-service, workspace-as-a-service, and so on.
This evolution is worth paying attention to, and moving to this architecture is the best architectural decision technologists can take today.
Functional sedimentation where the innovation of yesterday is a platform today, and cloud is the platform of today. It is no more an innovation.
Only those businesses exploiting the benefits of the cloud can survive in the business climates of today and tomorrow. Business leaders and technology leaders must adapt to the changes and build business models around delivering value to customers.
Want more insight on how the cloud will position your business for the digital economy? See Making The Leap From IT Complexity To The Efficiency Of The Cloud.