A Case to Unite Cloud + Devops for the Agile Digital Business

1 A Case to Unite Cloud + DevOps for the Agile Digital Business

Today, the practice of running business processes in the cloud is no longer relegated to entrepreneurial enclaves within enterprises. Instead, it is now at the heart of many mainstream organizations’ operations, supporting their digital business models. As a 2016 Forbes article so aptly notes, “Cloud is no longer a business strategy. It is just something we do.”

In fact, a growing number of enterprises have adopted a cloud-first policy in which the priority is on implementing cloud-based applications. There, teams need to make a compelling case if they want to deploy an app on servers, instead of running in the cloud. Driving such policies are a host of well-documented cloud benefits, including the ability to:

• Reduce and better manage costs by moving from the capital expenditure (CAPEX) of running technology on-premises to the operational expenditure (OPEX) of cloud services.

• Improve agility and the ability to get to market quickly with immediate access to cloud resources.

• Ensure high availability and optimal performance even during peak volumes by rapidly scaling cloud resources up or down to meet fluctuating demand.

At the same time, not all cloud strategies yield the same benefits. Simply migrating applications to virtual machines (VMs) in the cloud provides nominal advantages. However, enterprises can recognize double-digit gains in cost savings by breaking applications into microservices that run in cloud containers. Moreover, the greatest improvements in agility and cost reduction come from combining cloud technology with a DevOps Agile Stacks discipline. 2

Assuming your cloud stack is ready for legacy apps can be risky; have a game plan

In the following sections, this paper will examine the:

1. Comparative benefits of these three cloud approaches.

2. Requirements for creating a DevOps-enabled cloud architecture.

3. Roadblocks enterprises face in building and managing their cloud implementations.

4. Agile Stacks’ cloud automation approach to addressing these challenges.

5. Scenarios for getting started.

Lifting and Shifting Applications to the Cloud

Until recently, the primary approach for migrating to the cloud has been to take applications running on virtual machines on-premises, and port them to VMs in the cloud, or “lift and shift.” This facilitates the move from CAPEX to OPEX with the added benefit of elastic scalability to make more efficient use of cloud compute resources. Further benefits can be gained by taking advantage of cloud-enabled automation, such as auto-scaling, database as a service, and orchestration. This provides greater agility and eliminates the need for hot replication to support disaster recovery, leading up to a 50% savings in total cost of ownership (TCO).

Not all migrations using virtual machines go smoothly, though. Too often hardware dependencies or networking configurations, such as those with pre-baked IP addresses, or requirements for server proximity work fine on- premises but become difficult to port to the cloud. They may also not perform well on cloud hardware due to storage issues.

John Mathon is the founder & CEO of Agile Stacks. Previously a co-founder of TIBCO, he holds several patents. And he regularly shares his insights on cloud, DevOps, DevSecOps, and IoT at many speaking engagements worldwide. Follow him @john_mathon. 2

According to surveys, the challenges experienced by if the footprint of the OS accounts for 50% of a workload, companies who tried lift and shift applications to the using two containers instead two virtual machines can result cloud have moved 50% of those apps back to dedicated in a 25% savings of resources. Expand the environment to hardware due to poor performance or other problems. eight containers versus eight VMs, and the resource savings jump to 44%. Moreover, once the VM is up and running in the cloud, it can take each instance anywhere from minutes to hours to start up. For example, one company discovered that it took eight hours to start up its VM instance every time the IT group did an upgrade. Facing these migration and management issues, enterprises may find that moving to the cloud without re-engineering the app is not possible or not as effective as initially projected.

Given the challenges of VMs, more organizations are moving toward the adoption of container and microservices technologies. Increasingly new apps are Source: 451 Research (https://451research.com/report- short?entityId=90284&referrer=marketing) being built using a microservice architecture, while existing

applications are being re-engineered, so that the software Another container benefit cited by 451 Research is the ability pieces then can be pulled apart and turned into to spin up apps faster. Since a new OS instance is not microservices. needed for every workload, a container can be spun up in

In either case, the microservices can then run in cloud milliseconds instead of minutes or even hours. Moreover, containers. These containers are similar to VMs, but they containers offer greater agility, since during spikes in usage, have a much smaller footprint. Moreover, multiple only the containers in demand need to scale, which requires containers can run within a single virtual machine. They less time and resources than spinning up an entire virtual start up quickly and can be taken down just as fast. This machine. Thus container solutions are more responsive at a makes them ideal for microservices. much lower cost when a load builds.

Containers also are much easier to upgrade although there are more of them. If a container is used by many services, all The Case for Containers those services can be upgraded at once rather than one VM or app at a time. The only caveat is that container Containers provide enterprises a few important upgrades must be accompanied by adequate testing to advantages over using virtual machines. First, they are avoid introducing any errors. more cost effective because they provide operating

system (OS) virtualization, which enables containers to By contrast, International Data Corporation (IDC) estimates share a single operating system. By contrast, each VM that organizations spend 16 hours per year on operations requires its own OS. As a result, containers can basically labor updating each virtual machine. With thousands of VMs offer the same functionality while requiring fewer in some enterprises, the costs rise quickly. Overall, containers resources than virtual machines. deliver anywhere from 70% to 95% savings over the simple lift and shift of VMs, since it is much easier to change The firm 451 Research has developed a useful way to components and faster to update software with containers. calculate the comparative savings: (n-1)/n* (percentage footprint size of OS). The firm then shows how, for example,

The benefits offered by containers have escalated From a technical perspective, DevOps automates the worldwide adoption. Estimates put the growth of Docker process of software development, testing and deployment— container adoption at 35% to 40%, and there are more maximizing efficiency from idea to deployment. At the same than 14 million Docker hosts. time, it extends into organizational best practices aimed at establishing a collaborative culture for building, testing and At the same time, containers typically require IT teams to releasing software, enhancing quality. start from scratch. Therefore, many enterprises are deciding to refactor an existing application from a virtual A DevOps-first approach means that organizations not only machine to a combination container/VM solution. This shift applications to the cloud but those applications are enables a faster time to market than a total rewrite while enabled from the beginning with DevOps processes, offering significant operational advantages. includingfull continuous integration/continuous deployment (CI/CD) automation. This enables organizations to build

applications that will run well in the cloud, as well as provide

The Need to Move to a DevOps-First Policy the agility to respond to customers and make changes quickly, evolve the product rapidly, and in turn drive higher Cloud technology alone can provide significant gains, customer satisfaction. according to a survey of 929 senior IT professionals that was commissioned by CA Technologies and conducted by research firm Freeform Dynamics. Among survey DevOps and Cloud Form Early Connection respondents, CA notes, companies that make extensive use of cloud technologies have seen a 53% boost in Notably, many of the earliest software as a service (SaaS) performance compared to organizations that rely on cloud adopters were driven by their need for an effective traditional computing technologies. DevOps platform. These technical professionals required an API for nearly everything, from network resources and storage However, the greatest gains in performance were among to security, messaging or logging as examples, and the cloud the 20% of survey respondents that combine an extensive provided an effective platform for accessing and utilizing use of both DevOps practices and cloud technologies. these APIs. This meant that cloud providers were not only This group, identified by CA as the “delivery disrupters,” providing Infrastructure to companies but “infrastructure as have achieved an 81% boost in performance versus the code,” allowing organizations to program the infrastructure “slow movers” relying on traditional computing. Other they wanted in an automated way and expanding or gains among disrupters versus slow movers are equally reconfiguring it as needed. compelling: a 117% improvement in cost control; 90% increase in speed, 77% increase in predictability, 69% Later entrants have been attracted by the ability to take improvement in user experience, and 66% improvement in advantage of a SaaS application delivery model where new quality. features are released rapidly to meet customer demand. However, as these enterprises began moving to the cloud, a The advantages of applying DevOps to cloud-based number brought along their traditional IT processes with implementations make a compelling case for moving to a separate teams for developing and testing in the cloud, as DevOps-first policy focused on creating a lean, agile well as manual methods for approvals and operations environment where more reliable applications can be delivery. Because application developers were traditionally released faster and more frequently. Here, IT professionals separated from production and operations, a large would need to justify any decision not to adopt a DevOps disconnect existed, leading to higher error rates in making approach when implementing a cloud app. the transition from development to operations. This led to the need for more testing and operations oversight. 4

The resulting heavyweight processes associated with The bad news is that not all of the open source products traditional operations have hindered enterprises’ ability to work well together, and getting clear visibility across all fully capitalize on the agility enabled by SaaS. Faced with these components can be difficult—a case of not being this realization, more companies are now looking to adopt able to see the forest for the trees. As a result, building a DevOps to streamline their application processes across DevOps first architecture from these products can introduce development, test and production in order to compete in any number of risks, including: today’s market. • Selection risk – Are you looking at the best components in the category?

• Company risk – Are you looking at the risk the The Components of a DevOps-First Cloud Architecture technology is stale or going away?

• Technology risk – Does the technology actually solve Building a robust DevOps-first, cloud container-based the problem? platform is a complex endeavor. A typical • Integration risk – Will the technology integrate with other container/microservice cloud application will consist of 15- components easily? 30 components or more, and that is before developers • Performance risk – Does the component perform start writing applications. Additionally, since everything in adequately to meet your needs? the environment is interdependent, there needs to be • Security risk – Are there security gotchas including consistency from development to test to production. For Malware, poor coding practices as well as this reason, automating the deployment and inappropriate licenses for the component making your management of so many moving pieces in a production use illegal? environment can present a significant challenge. • Support risk – Is the component supported well should a problem occur? The good news is that a number of open source products • Training risk – Is the component documented well are available for most of the enterprise IT functions enough for you to use it easily across your group? needed in a DevOps--first architecture, so developers do Over time, these risks can change as the companies or not have to create everything from scratch. These technologies around the components evolve, and what products have global success and community support.

109

seemed like a good choice might prove no longer correct. Stack Consistency for Greater Reliability and Predictability Removing a component at a later time might involve Enterprises can mitigate the risks of integrating multiple substantial integration challenges and costs. And products by focusing on the development of stacks that are enterprises using these products today may find in five consistent across the three environments: development, test years a completely different landscape in which there is and deployment. This ensures that a change in one stack no support for some of the components in place, and will uniformly affect the others, promoting reliability and making updates will lead to substantial costs. predictability, while reducing development efforts and the IT teams have to pick components that satisfy all the related costs. architectural requirements of their applications, including For that reason, IT teams should consider standardizing components for security, self-healing, scaling, monitoring, container stacks. Having common stacks provides the storage, networking, CI/CD, and automation, among advantages of gaining experience that is shared across the others. Each of these components brings the risks enterprise and provides visibility into how the stack is described earlier, and it may take six months to a year to running, how reliable it is, how often it breaks down, and vet the right set of components and understand how they how to solve common problems—insights that are not will work together, scale, and meet the company’s available at the component level. performance requirements.

It is important that the components together, called a “full Adding to the complexity, the work and effort is repeated Stack,” are replicated carefully from development to test to by every group in the company and across the world. deployment into production so that the DevOps process Each group may decide on a different set of components works. Otherwise differences will manifest in unreliable leading to unrecognized dependencies on components production environments and difficulty tracking issues that and companies the team didn’t realize earlier. As a result, pop up with customers. the organization may end up with hundreds of different

components and no common knowledge across the A cloud architecture typically consists of at least two main company about the technologies being used in the cloud. stacks addressing different areas of functionality: the core infrastructure stack and the DevOps stack. For example, one group may be using Terraform and

Elastic Cloud Storage while another may be using Docker Core Infrastructure Stack and Kubernetes. And those are just two of many The core infrastructure stack supports a service or possibilities. More than 800 companies offer solutions in this application with core services that ensure security, reliability, area of cloud infrastructure. No single company offers a scalability and other services commonly used. It includes significant amount of this infrastructure via a one-stop shop cloud infrastructure services, such as networking and except for the platform-as-a-service (PaaS) consulting storage, which may be handled by an infrastructure as a companies, such as Pivotal. service (IaaS) provider, such as Amazon Web Services or a private cloud. It also features container-specific functionality, typically a Docker runtime with orchestration provided by Docker Swarm or Kubernetes.

Next is a layer that handles several performance and management functions, including networking, load balancing, service directory, log management, monitoring, backup and recovery, and vulnerability scanning, which

1112

are supported by a large selection of different products. At Other Stack Components Above the Stack Level the top of the stack is an application layer or stack that Additionally, there are several key functions within the cloud includes development tools, such as Java Stack or Node.js platform that extend across development, test and Stack. production versions of the stacks. These include the security The core infrastructure stack is the basic stack on which concerns of user administration, a catalog of stack everything else runs. Initially companies may start with a templates, a repository for certified containers, and usage smaller core infrastructure stack and add other core data collection to start. Stacks also should include various services over time as needed. Security scanning or storage options, such as NoSQL databases capable of networking components may be added. Meanwhile handling big data, relational databases, file systems, block logging, usage monitoring, performance monitoring and storage, or in-memory caches. other services are almost always required. Finally, the stacks may connect to any number of external DevOps Stack cloud accounts providing directories based on the Lightweight Directory Access Protocol (LDAP), databases, The DevOps stack provides the tools to implement CI/CD. and software as a service (SaaS) applications, for example, This stack runs across multiple infrastructure stacks and salesforce.com, Microsoft Office 365, Google G Suite, codifies the tools, processes and procedures to test and Concur, Slack, WebEx, and Docusign. 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 Best DevOps Cloud Practices Demand Automation other tools. A company’s DevOps team needs expertise in

the tools available today and in new or updated tools as Enterprises implementing a DevOps-first cloud need to they become available in this rapidly evolving market. consider automating as many processes as possible to achieve the agility required for today’s digital economy. The time to build is a critical factor in engineers’ Automation is particularly critical for large installations. For productivity. If they can build and test applications in 15 instance, a bank may have 150 to 200 groups developing minutes versus an hour, they may gain four times the applications. Each of those groups needs three productivity. Thus, fast builds are an important factor. environments: development, test, and production, bringing However, builds are unpredictable; there may be only one the total number of deployed stacks to somewhere that build, a dozen, or a hundred in process at a given time, could easily approach 500 or more eventually. Without the depending on the project state and number of users. That ability to automate key functions of the stacks, this would be is why having a scalable build process in the cloud is more nearly impossible to maintain in any cost-effective or timely effective than running build processes on fixed hardware. manner. Therefore, the DevOps stack, like the core infrastructure

stack, should provide scalability. Perhaps no company understands the power of automation in the cloud more than Google, which has Because automated testing is critical to CI/CD, DevOps spent decades building automation and systems to support stacks also need to include tools that help with cloud services. Notably, Google provides services that allow development, building, integration, automated testing for the company to build applications and test them at 1,000 functionality, such as WireMock and Selenium; times expected load. performance testing using Artillery; and security testing

using Blackduck or Clare. Enterprises can take a cue from Google in using automation to prioritize the allocation of hardware to key services, for

1314

example Google advertising. When hardware is available, Upgrades and Security Patching. It may be time-consuming different groups can use it, but when demand from core to track the changes and security patches for all the services peaks, the hardware access can be taken away components being used, and test the upgrades and on a moment’s notice. security patches against the other components and the application, but it is absolutely necessary. Because, any Similarly, development and test stacks can be deployed in change to the production environment can crash it, IT “spot” instances, which are machines that cost one-fifth to organizations must test every change before deploying. one-tenth the cost of persistent instances because a spot Given the critical nature of upgrades and patches, it is instance can be taken away at any point by the cloud worth examining these issues in greater depth. provider. Therefore, to leverage spot instances, automation handles periodic interruptions and re-deploys components taken away. Necessities for building an automation pipeline Looking more broadly, there are several operations that enterprises will typically need to have automated in their CI: Continuous integration production deployments. CD: Continuous delivery Deployment Automation. These operations include deployment, sophisticated deployment to different regions CT: Continuous testing or groups of users, partial deployment for some users, CS: Continuous security rollback when things go wrong, cloning an environment to replicate problems or to test new features, component CD: Continuous deployment upgrades, rollback of upgrades of components in case they go badly, and security updates. Addressing Upgrade and Patch Process Dilemmas DevSecOps Is the process of ensuring that automation preserves the security of the running production The sheer volume of upgrades and security patches can be environment. Enterprises that don’t make security part of large and costly if they are not automated. For example, their automation or that handle security inconsistently, or with 40 or more components in a typical organization, there implement security as a second step will open themselves will easily be 100 or more upgrades and patches per year. to unknown vulnerabilities. Meanwhile, a typical organization using virtual machines will spend 16 hours per VM per year. If there are 10,000 virtual Tagging Components and Versions. Another important machines in an organization, it may take many labor years automation task is tagging of the components and just dealing with their maintenance. collection of information about them to facilitate future debugging and assist in cost improvement exercises. In Containers are more numerous, and while they can be addition to optimizing the technical aspects of the upgraded more easily, there are still many risks from the deployment, consistent component tagging across the upgrade and patch process. Automating this activity is entire organization is important for enabling management critical so that rollbacks can be done quickly should a to assess the costs of various components and resources problem develop. Arguably, a better strategy would be to used across all components or some group. However, this build test scripts for the stacks, but doing so is costly and important process is often a missed piece of DevOps can’t be justified by each company. automation.

1516

Avoiding upgrades and patches is not an option, since this First, there are few training courses or places for companies will inevitably introduce the risk of “brittleness” developing. and their employees to learn best practices for DevOps. It is Brittleness is the situation where making one change to a a “dark art” to some extent at this time, and this leads system causes it to fail in some other part. Brittleness can companies to build a lot of infrastructure where they are happen for a number of reasons, and it leads to serious dealing with issues over and over as they learn by doing. problems as it becomes harder and harder to make This can include how to deploy upgrades to customers and changes to software. how to create new stacks on demand when new developers or projects come about. Brittleness can come about because of unknown dependencies between components. When a person Second, companies often repeat the mistakes of other changes one component, it can affect something else in enterprises due to a lack of shared knowledge. There is no unpredictable ways. Unless IT professionals become expert central place where everyone is sharing their experiences in everything and how it depends on everything else, they on all these issues except at conferences and in the latest will have no idea how brittle the system or automation may blogs of various organizations. be. Third, in order to find and eliminate problems, as well as Upgrading one component may require an upgrade of a reduce risks, enterprises must be able to replicate and clone different component. Upgrading that other component their stacks easily. This means having the automation to may break things the team doesn’t want to change, or it precisely replicate their production, test and development may impact a component for which there are currently no environments. In order to do this well, the automation needs upgrades. IT teams can mitigate these risks by upgrading to have the right abstractions and options for enterprises to components in a certain order or changing them at the deploy the stacks consistently in different environments. If same time. If an enterprise has multiple stacks, the IT the automation contains any specific reference to anything organization will want to automate this process. in one environment, when it is deployed in a new environment it will fail. Some companies, such as Red Hat, offer automated upgrades and security patching. However, if the upgrade or patch changes something that affects a component in A New, Higher-Level Organization: Stacks the enterprise’s stack, Red Hat probably doesn’t know

that, and this may break the organization’s stack. What has emerged from this discussion so far is the need for Therefore, enabling automatic upgrades by individual a higher level of organization beyond the component. The component providers is risky. Instead, enterprises need a concept of a “stack” is used to describe a service’s coordinated upgrade. components and integration at a higher level, so that it is possible to replicate, track and manage these stacks of

services across the organization. Gaps in Applying DevOps Automation Best Practices Without this higher level of organization, enterprises are left Too often, much of an enterprise’s automation efforts are with lists of thousands of components for which it becomes an afterthought. Usually companies are so happy to be up extremely difficult to automate basic operations without and running in the cloud they don’t consider what they are breaking other services. Stacks offer the ability to test things missing until a problem happens. Only then is the in repeatable units at a higher level. automation of critical functions incorporated into Maintaining such consistency is important, whether it is development. Moreover, enterprises seeking to embrace across different production environments—such as the DevOps automation often run into a few key hurdles. 9

1718

By contrast, using the control plane, IT management can understand the total cost of the stack, as well as get a breakout of specific aspects, such as the costs for data or security. With this level of knowledge, managers are empowered to make smarter decisions about how to manage cloud resources to reduce unnecessary expenses.

The Need to Manage Hybrid Clouds

Most enterprises will find that implementing applications in earlier example of a bank with 150 to 200 applications—or the cloud will require them to manage hybrid deployments different regions. For example, a company with operations that extend across multiple clouds or a combination of in Europe typically will need to have an identical cloud and on-premises environments. Even when deployment running on European servers due to data organizations try to adopt a single cloud, as different groups restrictions established by the European Union or individual in the company make technology decisions, inevitably countries’ governments. By automating the process there is pressure to utilize different clouds—whether to centrally, enterprises can ensure this consistency. support different business units or accommodate a Consistent stack organization can facilitate organization of company acquisition. Therefore, a key decision enterprises DevOps functionality. We call this a control plane. Use of a face in building their infrastructure stacks is whether to control plane also can eliminate much of the complexity depend on the infrastructure services of any one cloud or associated with manually running multiple scripts, which try to build solutions that operate on different clouds. perform whole operations on a stack. These many small Two primary options are a cloud-native stack and a cloud- scripts are reminiscent of a point-to-point integration independent stack. A cloud-native stack is an infrastructure problem that resulted in complex brittle spaghetti code stack that uses some of the services of a particular cloud found in evolving complex enterprise architectures of the vendor. This facilitates deployment but effectively locks an past. enterprise into that vendor’s solution. By contrast, a cloud- The control plane accomplishes the automation execution independent stack will use its own services, which of scripts by providing a central hub that incorporates an incorporate any number of solutions provided by vendors as orchestration engine, visual map, domain model, open source products and cloud services, but with different proactive monitoring, and cost analysis. Importantly, the capabilities and interfaces. Thus, porting from one cloud to control plane also takes advantage of the improved another can be made considerably easier by using a cloud- visibility provided by stacks to track and report on cloud independent infrastructure stack, making it an important costs. option for organizations that need to support IT across multiple cloud companies. Typically, insights into cloud implementation costs don’t go much deeper than what is available from a cloud In addition to these infrastructure stacks, some organizations provider’s invoice. This bill may state that the enterprise is are repeatedly building DevOps tooling in different clouds. being charged $3 million for using 100,000 servers in the Increasingly, they are deciding to create an underlying past month, but it doesn’t give a breakdown of whether platform for deploying stacks across different clouds without 80% or only 10% of the available resources were utilized. requiring individual teams to have DevOps knowledge.

2019

Ideally, the engineers building services within an enterprise efforts, there is very little opportunity to benefit from the should be able to choose the cloud where a service will be lessons learned by others due to the rapid rate of change in deployed, depending on cost, location or other features. the industry. As a result, IT teams around the world are Some companies are building a home-grown SaaS system learning about and solving the same problems over and that allows them to deploy stacks into different over. environments. Automation is essential and provides key benefits. However, At the same time, there are use cases where enterprises will as described earlier, it also presents many issues. IT teams still choose to implement a core service on-premises while need to write all the automation scripts and make them providing the ability to “burst” to a cloud when demand work with all the related components—and do so in a escalates, allocating machines on the fly. Additionally, IT secure way. Yet too few developers apply the same teams may simply find that some applications run better on software best practices to their cloud automation efforts. one cloud environment than another. Automation scripts should be considered as code. In the end, most organizations will need a system for Changing an automation script can affect the operation of monitoring—and providing a careful accounting of—all the the stack, so it is important to test any new or updated stacks deployed across all their cloud environments, automations to ensure that they have not broken something managing them uniformly and understanding and down the line. projecting the costs for each stack or service under When an organization seeks to reuse DevOps for another different loads. app, the DevOps as currently written may need to be significantly rewritten to support the new application. A robust understanding of how to evolve DevOps to support a Custom-Built DevOps Automation: The Challenge number of stacks is an evolutionary process.

Despite the wealth of DevOps and cloud tools on the At present, companies take it as a given that they will need market, enterprises face several hurdles in implementing a to spend 6 to 18 months building their first cloud DevOps-first microservices cloud container architecture. environment to include a DevOps pipeline and implement Primary among these is attracting and hiring DevOps a DevOps-first architecture. engineers with expertise in specific DevOps and DevOps best practices. These professionals have a comparatively The real problem, of course, is that writing clouds from rare skillset and are some of the highest paid developers in scratch should not be a necessary admission cost to the industry. As more companies move to the cloud and deriving the benefits of a DevOps-first cloud architecture. adopt a DevOps-first approach, the competition for these Isn’t there another way? experts will only get worse.

Enterprises also will need to hire experts in security, cloud The Agile Stacks Approach services, and cloud data, as well experts in implementing IT

system architectures with high reliability and scalability. Until now, organizations seeking to These are expensive resources and difficult to find and implement a DevOps-first cloud retain if firms can’t keep them busy with new exciting have had to make tradeoffs. On the challenging work. one hand, they can invest in a custom- built solution, which maximizes their flexibility in choosing Hand-in-hand with the staffing challenge is the fact that, available components but requires them to address the with each enterprise leading its own cloud implementation

2122

difficulties described in the previous sections. Alternatively, focus on implementing the operational pieces of their enterprises could choose an all-in-one solution from a PaaS solutions. The company is committed to making the use of provider. While speeding deployment, these the best-of-breed most popular tools easier, to give “opinionated” solutions are expensive, limit organizations’ companies maximum flexibility in choosing tools while choices, and can require heavy retraining of the technical providing best practices for security, automation, and team, making them difficult for companies to afford management known in the industry at any time. At the financially or strategically. same time, Agile Stacks provides tested, reliable automation, dramatically reducing an enterprise’s need for Now, with Agile Stacks, organizations have a simpler DevOps resources around the core components of its approach to deploying new applications than either build- infrastructure and DevOps stacks. your-own or opinionated PaaS-based alternatives. Agile Stacks implements a DevOps-first architecture out of the Robust DevOps Cloud Automation box, providing enterprises with the automation to deploy Agile Stacks is uniquely built to support DevOps in the cloud, an entire suite of 30 or more components in five minutes. providing CI/CD from day one and implementing a flexible At the same time, Agile Stacks lets enterprises choose toolchain that standardizes DevOps processes and tools. It among the most popular and best-of-breed open source enables the: products and deploy the tools that fit their use case—for

instance prioritizing on security or on performance. • Automated release of software, including automated application asset management and deploy processes. Depending on a non-proprietary variety of stack options

via Agile Stacks means being able to more easily adapt to • Continuous integration, including automated unit change in the market or to the changing requirements of testing and build processes, static code analysis, and applications or users. At the same time, Agile Stacks integrated build and deploy processes. components are integrated and work together from the • Continuous delivery pipelines with automation of the instant they are deployed using industry best practices. As entire software development lifecycle, from a result, organizations can have a DevOps first architecture development to test to production, allowing teams to deployed in minutes, ready for teams to build or copy a produce software in short iterations while guaranteeing service into immediately and be up and running much that new features can be reliably released at any time. faster than with any other approach.

• Automated operations, including automated event recovery; proactive monitoring, error detection and feedback; and the ChatOps open source chat box.

• Self-service environments with software-defined networking, security and storage, which can be automatically created and configured and offer autoscaling, auto updates, and error remediation.

• Autoscaling of the build tools so that builds and testing happen quickly regardless of the number of simultaneous builds or workload of engineers. Thus Significantly, Agile Stacks provides DevOps as a service (or keeping enterprises more productive and responsive to infrastructure as code as a service), so that enterprises can customers.

2423

DevOps Control Plane for Managing Cloud Environments resources were utilized. By contrast, using the control plane, IT management can understand the total cost of the The cornerstone of the Agile Stacks cloud automation stack(s), as well as get a breakout of specific aspects, such Service is the DevOps control plane, which simplifies stack as the costs for data or security or by any tag. With this level configuration and allows IT teams to create a of knowledge, managers are empowered to make smarter standardized set of cloud-based environments. Using the decisions about how to manage cloud resources to reduce control plane, developers can take advantage of unnecessary expenses. templates to configure a stack template that incorporates their preferred tools. The patented stack automation From the control plane, applications can be deployed in platform within the control plane then employs a hub portable containers or server-less functions and promoted model for automatic execution of the scripts to run the from one environment to another via an automated CI/CD stacks, eliminating the complexity and vulnerability pipeline—from development to testing to production. associated with point-to-point manual execution of scripts. Standardized, pre-integrated stacks developed from It also enables users to easily change components in proven practices and methodologies ensure quality delivery stacks and redeploy them reliably. while DevOps automation provides a high level of control and high-productivity. The control plane accomplishes automation execution of scripts by providing a central hub that incorporates an The control plane also plays a central role in managing orchestration engine, visual map, domain model, resources and costs through analytics that track usage data proactive monitoring, and cost analysis. by environment, microservice, stack, application, group, division, and business function, as well as costs, resources, and cloud metrics. As a result, managers have clear insight into performance and resource issues to support better decision-making.

With the Agile Stacks control plane, enterprises can also take advantage of more sophisticated cloud service options, such as spot pricing. With spot pricing, organizations pay only a small amount—pennies on the dollar—to use hardware resources that others do not need at the moment. This can be a particularly attractive way to reduce the costs of running non-critical apps. By taking advantage The Agile Stacks Control Plane menu lets users simply click on the of the automation scripts and analytics in the control plane, pre-integrated tools they want to use. IT teams can automatically spin up containers on either cloud infrastructure with available spot pricing or standard Importantly, the control plane also takes advantage of cloud services, depending on the established parameters. the improved visibility provided by cloud stacks to track and report on cloud costs. Typically, insights into cloud With Agile Stacks, organizations can get out of the business implementation costs don’t go much deeper than what is of building cloud environments and instead focus on available from a cloud provider’s invoice. This bill may delivering new digital services and applications that drive state that the enterprise is being charged $3 million for value for the organization and its customers—quickly and using 100,000 servers in the past month, but it doesn’t give cost effectively. a breakdown of whether 80% or only 10% of the available

2625

Capitalizing on the Agile Stacks Advantage Major cost reductions. The Agile Stacks approach eliminates costs associated with starting up in the cloud. It also By implementing Agile Stacks, enterprises can realize a reduces the maintenance cost for an organization’s number of important benefits, including reduced risk, faster DevOps over time, as well as reducing other expenses time to market, and significant cost reductions. related to maintaining the stacks. Because Agile Stacks

Reduced risk. Agile Stacks vets components and tests stacks incorporate many lessons learned in DevOps that combinations, integrates the components, and provides allow for more efficient operation, enterprise can cut the support across all of them. This drastically reduces many of cost of development and test stacks by 80% to 90% out of the incompatibility and performance risks associated with the box. developing a custom DevOps architecture. Other benefits enterprises can expect with Agile Stacks are

Faster time to market. As mentioned in previous sections, a faster builds, faster turnaround of features and bug fixes, custom-built DevOps automation can take five to ten more reliability in stacks, and better security. Additionally, experts within a company anywhere from six months to a the Agile Stacks control plane empowers organizations with year to complete—even longer for more advanced the ability to see their entire cloud costs and usage across DevOps functions. In fact, many companies are spending hybrid cloud environments at the stack level to support years working to implement Google-like DevOps better management and planning. Finally, IT teams will be functionality. Using Agile Stacks DevOps as a service able to upgrade, maintain, test and manage the eliminates development time along with the cost for those deployment of an enterprise’s stacks across all departments experts while ensuring a successful implementation. and groups consistently.

Agile Stacks’ SuperHub.io performs the automation turning user selections to actual infrastructure-as-code

2728

Getting Started Conclusion

In implementing a container-based DevOps cloud, Clearly, many enterprises can and have built their own enterprises are most successful when they begin with a DevOps clouds. However, doing so requires extensive small-scale effort to demonstrate early success that can resources to create and maintain these implementations then be evangelized throughout the organization. This while supporting the rapid evolution of market demands may be a top-down move, such as implementing the and technologies. In many cases, organizations find cloud to support a new project or product team, or a themselves in a continual state of catch-up. bottom-up action, for instance spinning up a cloud stack By implementing the Agile Stacks cloud automation service, for a new developer joining an existing team. enterprises can quickly get up and running with a robust Typically, green field projects, including new applications DevOps cloud environment designed to meet the speed or digital services, provide the easiest scenarios for and scale of today’s digital businesses, supported by: implementing new cloud environments. However, the • High agility by bringing CI/CD to the cloud. automated stacks provided by Agile Stacks can • High reliability, security and scalability to support accelerate the process of taking an existing application enterprise-class demands. VM and breaking it into components and microservices • Greater insight and functionality to minimize costs. that can run in cloud containers. In some cases, A flexible infrastructure to meet deployment organizations already have some automation scripts in • requirements. place. By putting the Agile Stacks DevOps Automation • The ability to adopt the latest technology without the Service on top of the stack they already have typical integration pains. implemented, the IT teams can more easily implement • Optimized operations through built-in best practices security best practices, get a better view of the and automation of everything. architecture, and better manage costs. With Agile Stacks in place, enterprises are now better positioned than ever to focus their expertise on innovating applications and digital services that drive revenues,

growth, and customer loyalty to compete in the worldwide, digitally driven economy.

About Agile Stacks

Agile Stacks is reinventing how enterprises implement clouds with its Agile Stacks DevOps automation service. For the first time, organizations have a DevOps-first architecture out of the box that empowers them to deploy full- function DevOps cloud stacks using their tools of choice within minutes. Incorporating a range of popular, best-of-breed open source products that are pre-tested, integrated and work together from the instant they are deployed, the stacks support the predictable performance, agility, scalability and reliability required for today’s digital businesses. Founded in 2016, Agile Stacks is headquartered in San Mateo, CA, and it is backed by investments from Canaan Partners.

Agile Stacks, Incorporated www.agilestacks.com 1450 Parrott Drive, San Mateo, California, USA

Contact [email protected] +1 (650) 204-9018