The need for speed: A tale of DevOps and Microservices

Our recommendation is to start small, identify a representative application and allow your teams to get comfortable with the DevOps culture. The goal should be to build templates and processes which can be re-used for other applications and future projects.

The other important aspect is to define how you calculate the return on investment, which must be established to take the process forward.

Customers have been focusing on cloud migration, automation and improving the resilience of their current processes. We have seen a lot of adoption of DevOps in the recent days by organizations who were yet to do so, and COVID-19 has undeniably nudged them in that direction.

To accelerate such adoptions and skill gaps, we have built accelerators, which include reusable templates, which can serve as a foundation to address most of the challenges one would face.

We calculate the savings in terms of:

• Number of deployments and time taken
• Number of issues post release (before and after DevOps implementation)
• Number of work items moved
• Amount of time taken to build, deploy and completely test the code before releasing to production

Whilst the above are quantifiable metrics, there are other observable benefits such as customer satisfaction, faster project delivery, and ease of operations from a development perspective.

Some of the key pitfalls to avoid are:

• Creating a dedicated team upfront for DevOps implementation
• Starting DevOps for all projects simultaneously
• Disregarding the cultural impact and importance of team participation
• Starting off with expensive tools
• Picking extremely complex processes - this often leads to delays and also reduces the morale of the team

It saves time to fix security bugs as security practices are already baked into the larger processes.

There isn’t a need for a formal training on DevOps, but an education on Agile practices will help.

DevOps helps make the most out of an organization’s cloud investments, especially in the automation area, which is the prime reason for DevOps to be implemented post migration.

Solutions around containerization and orchestration implemented on-premise help switch to the cloud sooner.

It saves time for development, QA and production support teams, and helps assure that the code which has been tested and signed off on, is the one delivered to production.

Also, post production, should there be a need for a rollback, a standardized approach helps you prevent further issues and reduce outages.

Startups have one advantage over enterprises. They can start small, perfect the process, and keep building upon it.

Enterprises have a challenge wherein the applications are already built, and would need to be standardized. Hence, it’s recommended that enterprises focus on bringing in the required cultural change and pick smaller projects, stabilize, and then look for more complex systems.

The benefits of validating your containerization strategy on-premises are as follows:

• Implementing containerization on cloud infrastructure would mean you would have to start paying for the infrastructure even while it was being tested
• An on-premises containerization strategy would help you validate application behavior on multiple parameters like security and performance. The orchestration architecture would be tested without the added pressure of infrastructure costs

Architecture and strategies, to an extent, depend on your business use case and on your application. Many people hurriedly transition to the cloud only to realize that they need merely one or two instances of an application, and do not need the elasticity or scale that comes with the cloud. They have a predictable workload, and could instead use APIs internally to spin up things on private instances. Many get drawn in by the hype of cloud and containerization without properly evaluating its suitability for what they're trying to build. That is the biggest challenge organizations have - Is the solution even suitable for the business they are running? What are their users actually looking for? What is the architectural mapping needed in order to have elastic platforms?

The pillars of a cloud agnostic strategy are:

• Tools
  • Identifying the tools that can support both on-premises and cloud infrastructure
  • Evaluating which tools fit best, from a CI/CD, security and infrastructure provisioning point of view
  • For CI/CD, tools like Jenkins, Bamboo, Octopus Deploy, CircleCI and several others could suffice depending on the precise need
• Processes
  • Updating IT processes to accommodate for provisioning
  • Managing costs
  • Deciding what cloud the application stacks should be hosted on
  • Performing security processes like vulnerability assessments, threat detection etc.
• Team Skills
  • Updating team skills well in advance, before embarking on a multi-cloud strateg
  • This helps teams identify the right setup and develop automation to make the most out of cloud service providers
• Finally, we need to figure out reduced toil methods first. One can start validating the architectures on-premises, and on a single cloud, before moving to a multi-cloud environment. Multi-cloud environments, though complex, are manageable, if we develop maturity by gradually releasing staff from the efforts wasted on toil.

Start by defining each step in the SDLC and then measure efficiency based on the time spent on, and the number of iterations for, each of these steps. One can start with a value stream mapping by breaking down the amount of time it takes for each of the tasks in CI/CD pipeline

• Time to build code
• Unit test
• Static code analysis
• Deployment
• Rollback time

Some of the key metrics are as below

• Total time saved vs. Cost saving
• Reduction in number of issues post go-live
• Total time taken to go live before and after DevOps implementation
• Time taken to provision the infrastructure
• Number of issues post infrastructure setup before and after automation
• Number of security vulnerabilities detected post go live

Instead of letting tools define processes, the technology selected should support the process to keep management overheads in check. A good process is needed to manage and deliver application and cluster updates, and releases must be orchestrated.
Some key enablers would be:

• Building reusability
• Infrastructure as a code
• CI/CD pipeline
• Standardization of process
• Educating the development team on DevOps
• Starting small with just one or two projects, building upon their success, and then expanding

A major chunk of losses occur due to inefficiencies. Bad methods cost money due a number of reasons such as:

• The team’s awareness of the cost impact
• Lack of maintenance
• Scaling when not required
• Choosing incorrect options / services in the cloud infrastructure

Such issues can be avoided by proper training and development of processes such as:

• Automating the provisioning of infrastructure
• Implementing AIOps – integration of ITSM tools and infrastructure provisioning processes with automated approval gates
• Training the team on the risks of non-compliance and bad designs
• Benchmarking costs before deploying infrastructure
• Evaluating the right options before rolling out infrastructure

The aforementioned processes baked into architectural design and infrastructure automation solutions, help ensure that the infrastructure delivered is of the same standard, and costs are predictable

For startups, the primary business driver is time to market, not security, operations, stability, or SLAs. The goal for them is to go to market with a product. Therefore, a dev-centric approach in a startup might be ideal because developers can focus on agility and speed, which is what a startup needs. They can roll features out as fast as possible. This approach does not consider (in many ways) security and SLAs, which is acceptable from a startup.

However, the same might not work with enterprise features. Enterprises can't run dev-centric. They need to be tri-centric i.e. the stakeholders and bailiwick of ops and security must be baked in with development. Enterprise businesses are not driven by the objective of being sold. You cannot afford to damage the brand, not comply with regulatory provisions, or damage NPS - which are things that enterprises survive on over decades.

Startups are recommended to be dev-centric and focused on going to market with as many features as possible. The same, however, cannot be true for an enterprise. If you take a dev-centric approach, you stand to damage a brand that's worth billions. Hence, my recommendation is to go tri-centric – bringing together the operational bailiwick and expertise, the security bailiwick and expertise, and involvement within the CI/CD process through security fitness or conformance, within the orchestration layer. Through these, you can achieve regulatory requirements, governance, and operational excellence.