In the previous post, I mentioned that we are the advent of a new era of glorious distributed computing of many kinds, and therefore, infrastructure has to be reimagined to meet the evolving needs and challenges. In this article, we will explore how de-centralization via micro-services and external services is impacting application development and deployment.
Applications have, in the past, had a form of centralization in the form of being a monolithic, tightly bound development and deployment model. Also, there was an approach of slow and rigid waterfall development, which was holding back the speed of innovation, enterprise digital transformation.
But then, a few major movements happened at about the same time: cloud adoption, continuous integration continuous deployment (CICD) and microservices. These three trends together have created a seismic shift in the speed and flexibility of development and deployment of applications. Let’s elaborate on each of them in turn.
In my view, cloud adoption was the first to break open the application deployment log-jam. Prior to the cloud, business units that want to deploy innovative new services had to beg the IT team for resources in the data center, which were constrained. Lead times were several weeks to even months! Deployment was also slow-moving due to decades-old, hide-bound IT deployment processes. App-dev teams in business units were Frustrated with the slow pace of progress and stymied innovation.
But the advent of the cloud IaaS and PaaS let business units experiment with innovative functionality by app teams themselves quickly deploying on the cloud, without having to wait for IT resources or even approval because of the pay-as-you-go incremental op-ex model rather than large capex purchases ahead of any deployment. This broke open the log jam and started the process of distributed deployment and operations.
Dev-ops / CICD
Partly spurred on by the cloud adoption and also independent of that (for on-premise deployments), the centralized deployment model got broken up, with only infrastructure procurement and operations being left with IT and the application deployment and operations being entrusted with the new breed of staff integrated within the business units, which came to be known as dev-ops.
In addition, application development teams started to rev up the innovation engine by consigning the waterfall model of development to the dust heap of history and adopted the model of agile development and continuous integration and continuous deployment (CICD).
In the waterfall model, there would be a significant period of requirement gathering, followed by specification, design, development, testing, and then deployment. Each release of the application would then take several months or even years with a big step up of functionality with each release. This approach not only created a delay between each batch of new capabilities, thus making business innovations happen in fits and starts, it also risked a newly released functionality already being out of date with the business needs! That, in turn, created a huge impedance mismatch between business needs and rate of application improvement.
Therefore, application teams adopted the model of agile development where functions were broken up into small chunks of requirements and incrementally developed in a small number of weeks. These incremental functional improvements were then quickly integrated and deployed into production use rather than waiting for months. Since several apps were being delivered as SaaS, there was not a long upgrade delay; the SaaS could be upgraded quite often without disrupting users.
This approach came to be known as continuous integration / continuous deployment or CICD, which, when layered on cloud deployments, tremendously revved up the ability to develop and deliver innovative new capabilities to market. Also, small tweaks could be tested in parallel for different sets of users, allowing the best new capabilities to move forward and the ones which did not find sufficient user adoption and approval were quickly junked. In other words, application development adopted the natural selection approach of biological evolution!
The adoption of cloud for rapid deployment and the advent of CICD model already loosened the grip of the outdated, rigid centralized model and ushered in the modern era of distributed deployment. Then came the coincident revolution in application development: microservices.
Enterprises observed that the pace of innovation speeded up when entrusted to respective business units rather than central corporate IT department. So why not further decentralize within app-dev teams to further amp up flexibility and speed?
There had been already a recognition that disaggregating applications into services enabled more rapid delivery of new functionality. The earlier incarnation of this was the availability of middleware architectures such J2EE that mediated between end user-facing apps and backend common services. Enterprises also tried services-oriented-architecture (SOA) to spur this model.
While the services approach did induce some level of flexibility, due to various technical complexities, the services approach never reached the ultimate fruition. The services themselves tended to be large and monolithic, inhibiting rapid change.
The situation changed when some fast moving e-businesses such as Netflix adopted newer, much lighter-weight services, each with just a few functions. They were able to decompose apps into ever smaller services, which were eventually so tiny and so numerous that they got the label “Micro-services.”
The major advantage of the micro-services approach is that since the interactions between the services are clearly defined by an application programming interface (API), each service can be developed and improved by a small, self-contained team, leading to a much higher pace of innovation. Thus not only has the monolithic app been exploded into microservices, but application development teams themselves have become decentralized! This trend has now taken hold in most enterprise app dev teams.
API’s were already being used to export enterprise functionality to the external world, for end-users and extra-nets. However, the micro-services revolution took the use of API’s for internal use (the so called east-west traffic) to a whole new level. And that’s not all! Now, enterprise applications are even being composed of not only internal services but also incorporate functionality from outside the enterprise. A simple example is overlaying available inventory of stock on a mapping service provided by an external party. There are numerous other examples, such as utilizing billing services, credit card authorization services, etc.
Distributed Era of Apps
Combined, the cloud, CICD, and Microservices have now engendered the era of distributed, agile development and deployment of applications to speed up innovation and amp up flexibility.
The advent of containers and orchestration systems such as Kubernetes have accelerated such deployments and made it easier for enterprises to adopt hybrid and multi-cloud deployments, making this era of apps ever more distributed. This trend has created several stresses as well as opportunities in infrastructure.
Some of the notable challenges are:
- Lack of visibility of which services talk to which, and the sensitivity of data carried between them
- Lack of visibility of how the services are layered on virtual constructs such as containers, which in turn are layered on underlying cloud infrastructure
- Dissolution of the perimeter and need for zero-trust security of API interactions
- Flood of metrics from countless services and containers leading to a very long diagnosis and repair times cutting across independent service teams, each with its own phalanx of tools!
- Services spread across hybrid and multi-cloud, leaving possible security holes vulnerable to breach.
Some of these challenges and potential solutions have already been discussed in earlier articles by founders of companies that have been co-created by The Fabric:
In addition, the increased ability to manage distributed deployments and decompose apps into right-sized containers had brought about an opportunity to complement the over-centralization onto a few public cloud deployments with a distributed edge infrastructure. We will explore that trend in the next article of this series.