fbThe need for speed: A tale of DevOps and Microservices | ValueLabs

The need for speed: A tale of DevOps and Microservices

icons Register Now
Register Now
Speakers
Kris pic
linkedin icon
Kris Buytaert
Co-Founder and CTO at
Inuits
Rohini pic
linkedin icon
Rohini Khanduri
Director – IS at
Ingram Micro ITAD
Shlomos pic
linkedin icon
Shlomo Bielak
CTO at
Benchmark Corp
Summary

DevOps and Microservices are amongst the hottest trends within IT. DevOps is the combination of culture, processes and tools to deliver software and applications at a faster pace. To be able to reap the true potential of DevOps, it is often necessary to design the application in a way that it enables rapid changes with minimal impact. This is where Microservices play a key role. Microservices break down complex applications into several smaller manageable independent services. Combining Microservices and DevOps methodologies significantly improves both the speed and quality of your application.

Market analysis has shown that the DevOps and Microservices ecosystem is set to display global growth at a robust CAGR 16% between 2019 and 2024, reaching $10 billion by 2023. Firms that move towards integrating DevOps and Microservices will benefit from the agility, reliability and scalability provided by the combined ecosystem, while those failing to do so could be at a competitive disadvantage. It is however key to clearly assess the architecture of your application before embarking on this journey.

To learn more about creating an effective integration strategy for your IT infrastructure, join our panelists on 10th December, 2020.

To know more about our Digital Transformation services

FAQ

What’s your advice to someone who is just getting started with DevOps?

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.

Do you think the current COVID-19 scenario will affect DevOps adoption – will it be adopted more in the coming years than it has been traditionally?

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.

How have you gone about demonstrating the return on investment in your DevOps journey?

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.

Based on your experience with leading DevOps transformations, are there any pitfalls you would recommend avoiding, and if so, how?

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
What additional advantages does DevSecOps offer above DevOps?

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

What role does formal training play in helping adopt a DevOps culture?

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

Does DevOps play a key role in the cloud migration journey?

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.

Why does simplifying CI/CD matter the most for DevOps?

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.

Should startups and enterprises approach DevOps adoption differently?

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.

If I were transitioning from an on-premises and container less architecture to the cloud, why would I want to create an on premise container strategy first?

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
What are the architectural best practices to follow while creating a cloud-agnostic strategy? How can we ensure this from the beginning?

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.
What metrics should we track for measuring effectiveness?

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
What are the key enablers for efficient DevOps in terms of technologies/cloud tools?

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
What are the potential monetary losses related to public cloud? Are they related to accidental elasticity, or something else?

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

Should the approach to DevOps be different for startups and enterprises?

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.