There’s a popular definition of insanity: doing the same thing repeatedly but expecting different results. Yet, too many enterprises implementing digital services and apps in the cloud fail to heed this warning as they turn to point-to-point integration of their cloud components. In the process, they’re introducing tremendous complexity that looks eerily similar to the point-to-point application integration headaches companies faced before the concept of centralized mediation emerged some 15 years ago.
Consider the scope of the challenge. A cloud deployment can contain 30-plus product components that need to be integrated to run together smoothly. At any time, an update to one of these products can break processes that rely on the other components. DevOps compounds the complexity, since teams need to ensure consistency across development, test and production environments. It may be fine for a dedicated DevOps team in the group to handle these environments when there’s just one project. However, as the number of applications utilizing cloud technology grows, it is expensive to have DevOps teams build each environment as a wild west project.
Standardizing on Stacks
A saner approach is to implement a cloud architecture that standardizes on stack-level operations. Implemented effectively, a stack serves as the reference architecture for all the components and automation needed to create a replica of your production environment. This “full stack” is in essence much like the configuration management database (CMDB) once thought to be the holy grail of enterprises.
With a meta-description of your full stack for a service or application in place, it becomes possible to deploy identical copies for development, test and production, as well as automate DevOps across your application. This ability to duplicate stacks removes the barriers to, for example, deploying multiple test environments or multiple copies of the stack for security compliance or disaster recovery.
The stack is an important concept for understanding how you are building and running your software. If something goes wrong, it also provides visibility into what is running, how it was deployed and what the problem might be, facilitating the ability to systematically correct the problem and deploy the fix to all needed replicas. Developing a stack concept also lets you track applications—plus the associated tools, development practices, cloud practices and vulnerabilities—across your organization, providing a critical step in the maturity of your enterprise’s cloud development.
Standardizing on stacks enables development teams to focus on building new applications and services rather than spending six to 18 months implementing the cloud architecture. At the same time, different groups may require different capabilities, making a one-stack-fits all-approach impractical. The middle ground is to provide a set of “sanctioned stacks” or a portal for configuring stacks, which limits options to products that have been pretested to confirm they work together.
Structuring DevOps Cloud Stacks
A DevOps cloud architecture will consist of at least two main stacks: the core infrastructure stack and the DevOps stack. Increasingly, these stacks run in containers, which provide two key advantages: a greater agility through the ability to spin up apps faster and more cost-effective use of resources through operating system-level virtualization.
The core infrastructure stack supports a service or application with services that ensure security, reliability and scalability. It includes cloud infrastructure, such as networking and storage, which may be handled by a public cloud platform or a private cloud, along with container-specific functionality, such as a Docker runtime with orchestration provided by Docker Swarm or Kubernetes. The stack also has a layer for handling performance and management, including networking, load balancing, service directory, log management, monitoring, backup and recovery and vulnerability scanning, which are supported by a range of different products.
At the top of the core infrastructure stack is an application layer or stack that includes development tools, such as Java Stack or Node.js Stack. More advanced application stacks will go beyond tools to provide the blueprints for migrating from monolithic apps to containers and microservices.
The DevOps stack supports continuous integration/continuous deployment (CI/CD). It runs across multiple infrastructure stacks and codifies the tools, processes and procedures to test and deploy or rollback changes to the infrastructure stacks. It typically incorporates DevOps instructions using Chef or Terraform, Ansible, Puppet, Swarm, Helm and half a dozen other tools. Because automated testing is critical, DevOps stacks also should include tools that help with development, building, integration, automated testing. Popular options include WireMock and Selenium for testing web apps and services, Artillery for performance testing and Blackduck or Clare for security testing.
Additionally, there are key functions within the DevOps cloud platform that extend across development, test and production stacks. These include security, a catalog of stack templates, a registry for certified containers and usage data collection to apply predictive analytics for performance and cost optimization.
Introducing Stack Automation
Enterprises implementing a DevOps-enabled cloud need to consider automating as many processes as possible, particularly for large installations. For example, a bank may have 150 to 200 groups developing applications. With each app requiring environments for development, test and production, that means anywhere from 450 to 600 deployed stacks to maintain.
Significantly, updating stack components needs to be a coordinated process. It’s not enough to rely on automated upgrades and security patching provided by individual product vendors. That’s because if the upgrade or patch changes something that affects a component in the enterprise’s stack, the vendor probably doesn’t know that and this may break the stack.
Automating stack functions in a coordinated way is best accomplished using an intelligent, centralized “command center” portal that incorporates a central orchestration hub. This eliminates much of the complexity associated with manually running multiple scripts by performing whole operations on a stack. Whether your organization builds it or you use a third-party solution, this hub for automating the execution of scripts should incorporate an orchestration engine, visual map, domain model, proactive monitoring and cost analysis.
Importantly, a command center incorporating an automation hub lets you take advantage of improved visibility provided by stacks to track and report on cloud costs. Moreover, you can capitalize on “spot” instances—costing five to 10 times less than persistent instances—by using the hub to automatically handle periodic interruptions and redeploy the components taken away.
Through automated stacks, your organization now has a sane way to cut the complexity of implementing a DevOps cloud while providing an agile platform to support your development team’s innovations.