In this article, we discuss Modern Operations, and what it looks like in an enterprise environment. We’ll also discuss the advantages of modernizing the technology stack and development practices in an enterprise. Finally, since everything good comes at a cost, we’re going to have a very candid and open conversation about the foundational elements you’ll need to put in place to ensure that your modernization strategy pays off.
Let’s begin by discussing what we mean when we talk about modernization and what it looks like in an organization. We do provide an overview below, but keep in mind that every organization has its own flavor and culture associated with technology. You’ll want to consider how this fits into the overall goals and strategies of your company, and enlist the help of experts where it makes sense (and of course the Weaveworks team would be very happy to help you out in this case).
What Modern Ops Looks Like
Modern Ops describes a trend among technology companies to embrace cloud-native architectures and development practices like GitOps. Cloud native has more to do with how we develop and deploy our software and less about the location of the final deployment. The emergence of cloud hosting services such as Amazon’s AWS and Microsoft Azure has had a significant influence on how we develop software.
The core components of Modern Ops / Cloud-native development process are:
- DevOps / DevSecOps
- Continuous Integration / Continuous Deployment (CI/CD) pipelines
- Microservice Architecture
DevOps / DevSecOps
The concept of DevOps came about due to the convergence of development and operations teams. In the past, developers would build an application, QA engineers would assess the quality of the changes, and then an operations team would deploy and maintain the application. It was a process that worked, but it wasn’t great. Generally, a lack of ownership sometimes led to a lot of finger-pointing and dissemination of blame when things went wrong.
DevOps is all about ownership. The team owns the development of the software, extensive testing and deployment, and support of the software product. While this may sound like a lot, with the right approach to development, and the support of a reliable CI/CD pipeline, it works exceptionally well.
DevSecOps is a more recent evolution that involves a security focus when building and deploying applications. Given the growing threat of malware and other vulnerabilities, ensuring that security is baked into our development practices right from the start will better protect our organizations and our consumers, moving forward.
Continuous Integration/Continuous Deployment is the process of including software updates frequently, thoroughly testing them, and deploying them into the production environment. A critical ingredient of this is to focus development efforts on small, frequent changes. By continually integrating changes, thoroughly testing them, and deploying them into a production environment, we limit the scope of new changes and can quickly roll back, or fix bugs rapidly.
Testing in a CI/CD pipeline takes the form of an automated testing suite. The pipeline automatically administers all unit tests, integration tests, performance tests, and checks such as static code analysis, vulnerability scanning, and code coverage whenever we add or modify our code repository. If the new build passes those tests, we can deploy it into our production environment, and monitor it to ensure that it performs the same or better than the previous version.
The core tenant of microservice architecture is that you divide your application into small components, each tasked with a specific purpose. An example of this could be an e-commerce organization. When a customer pays for a service or product, they could pay with a credit card, gift card, offline bank transfer, or PayPal. A separate microservice could support each one of these payment options.
One advantage of this approach is that a bug in the PayPal microservice only affects that service. When the responsible team resolves the bug and deploys a new build, they can deploy a new build without having to deploy the rest of the application.
There are two additional concepts that I have found to be invaluable when talking about microservices. These are the domain-driven design and API first development.
- Domain-driven design involves dividing your organization into groups based on shared functionality. Using the example above of an e-commerce organization, you might have a payment domain, a product catalog domain, and a user experience domain, among others. Each domain is responsible for developing the services for their domain.
- API first development is the process where new development begins with the development of an API contract. Especially in highly collaborative environments, an API contract establishes the means of communication between services. The development team builds its services based on the contract, and dependent teams can build their applications, knowing exactly how they can expect to communicate with the new service.
The explosion of container-based services in the past few years has phenomenally enhanced our ability to build stable and scalable microservice-based applications. We can expect a microservice built and packaged as a container, to behave the same on a local workstation or in a test or production environment.
By using a container management system like Kubernetes, we can support highly available, fault-tolerant, and scalable systems with relative ease and confidence.
With declarative constructs such as Kubernetes, configuration can be kept alongside code in source control such as git. Combined with the immutability of containers and microservices, you have the ingredients to fully automate your entire development and operations pipelines. With everything kept in git and used as a single source of truth you can deploy agents to monitor and compare the source of truth with the running cluster. When there is a discrepancy an alert is sent. This effectively creates a feedback and control loop that allows you to maintain, or rollback changes to a cluster.
With this type of automation, developers can use pull requests as usual to make updates to apps or services running in the cluster without having to log into Kubernetes. Operations can also use pull requests to make updates to the cluster, and to its platform. They are also able to easily meet compliance regulations with a full audit trail of who did what to the cluster all kept in git.
The Benefits of Modern Ops
In today’s competitive world, you achieve success by delivering value to your customers, quickly and efficiently. The principles of DevSecOps and Modern Ops, which we discussed above, enable you to design your application and your development practices to support speed and reliability.
If appropriately implemented, Modern Ops empowers teams with a sense of ownership and the ability to pivot and adapt as needed. In the current technical landscape, the cost of not adopting a Modern Ops approach is likely to grow in the form of lost revenue and customers.
Everything Comes With A Cost
While adopting Modern Ops has many advantages, it’s also not a decision to be made lightly. A poorly executed implementation plan can cause more harm than good. Begin with a plan, and a clear objective of the type of Modern Ops landscape, and enlist the help of experts to review it, and improve it.
You’ll need to get buy-in from your organizational leadership, as well as your development, QA, and operations teams before you begin. Your success depends on their willingness to support and adopt a new way of building and deploying applications.
Some critical keys to your success are ensuring that your plan focuses on agility, security, and quality. An essential component is a pipeline that builds and deploys new applications. As much as possible, you want to automate checks for code quality, security to make the process as seamless as possible, and minimize the work engineers need to do.
Automate, automate and automate some more.
Finally, Modern Ops is about a culture shift. Engage your engineers and your leadership teams. Ensure they understand the end goal, and that they have the resources and tools necessary to achieve that goal.
Just starting out with Kubernetes?
Excited about the opportunity of cloud native and GitOps but not sure how to navigate your organization to the path to success? Whether you’re using Kubernetes in the cloud or behind the firewall your team needs battle-tested architectures, workflows and skills to operate Kubernetes reliably. Our QuickStart program is a comprehensive package to design, build and operate Kubernetes in production using the GitOps methodology. Contact us for information.