You CAN change your Culture if you want to Maximize value
In my previous post, I said:
DevOps is fundamentally a software development practice.
To adopt this software development practice, we have to change the software development culture. A mindset shift is needed:
“We are a software company with wings” — CIO of an Airline company
Any organization can adopt this mindset and create a modern software development culture if you want to maximize value. The way to maximize value is by reducing cycle time.
“Speed wins in the marketplace” — Adrian Cockcroft, Netflix, Battery Ventures
Make speed your friend. Every organization can deliver at speed and scale without sacrificing quality.
In order to deliver software faster, the software must be built as independent services that can be stitched together via contracts (REST API’s) to form an Application or System. Monolithic systems have too many dependancies where things slow to a crawl.
Applying the Time Value of Money Principle to Software Delivery
Applying the time value of money principle is the key to unlock the value. So, why are the biggest enterprise not delivering software today or multiple times a day? It’s not that they don’t want to. It’s because after years of being in business, they have built up a lot of applications and systems. It’s not that easy to transform your software development organization much less the applications. Adapt they must though. However, the main issue is to recognize that if you want capture value fast, then the value needs to be delivered — ie. Running in Production. The more frequently you deliver that value, the better the return. It’s like compounding. If you deliver once a year or once every 18 months, it costs you the same total amout of development resources but you have delayed the capture of that value by a year or 18 months or more. Whereas, if you deliver value today or tomorrow, you can start capturing that value today or tomorrow.
Align your teams to business value.
Aligning your teams to business value. How? By creating modern “2 pizza teams” that can build services independently.
Organize your teams using Conway’s law
There’s a way to retool your software development organization so that your teams that can deliver value faster by building services independently. Conway’s law, which basically states that organizations that design systems “are constrained to produce designs which are copies of the communication structures of these organizations.” The implications for software development are rather simple: the structure of our software is likely to reflect the structure of our software development organization.
If the organization has separate horizontal teams that each own different elements of a service, for example, one team owns the API layer, another one owns the business logic, and a third owns the data layer, then the virtual team that has to build a service that consists of all three have to constantly negotiate with the priorities of the horizontal teams. These siloed teams will have their own priority so if a team that is building “Service A” has to deliver a solution, they have to negotiate separately with each of these teams and this slows down the process. Creating virtual cross functional teams is simply papering over those communication boundaries. This is not going to achieve the speed, quality and risk profile that you need to deliver value faster.
This is a BAD idea
By creating vertical teams for each service where the team owns the API, business logic, and the data layers, the teams are no longer dependant on any other team. The key is the API layer. This is used to form contracts between different vertical teams so each team can move at their own pace and use the API to integrate or leverage other services from other teams.
Best Practice — Follow Conway’s Law
Best practice — Follow Conway’s law for teams that are building services that make up the system or application.
In order to deliver value fast, teams must be organized in a way that allows them to own it end to end. What Amazon calls — “you build it, you own it” through its entire lifecycle. But what is it that they will own and how many cooks do you need in the kitchen to own it?. That’s what we have today with Monoliths. Large teams of 100’s or 1000’s can’t possibly “own it”. The only way to have responsibility assigned in a way to measure accountability, is to empower “2 pizza teams” that own something end to end. This something is a service. A service does one thing and one thing well — single responsibility principle. Whether you call it a microservice or not, doesn’t really matter.
Team composition
A modern team is ideally 6–8 people, no more than 10. They own everything from development to operations including quality and product management. Developers are on PagerDuty. The team is responsible for the quality of their service in production.
Unlike a monolithic architecture, a microservices architecture allows you to scale the teams and number of deployments as you grow your business.
Docker is an enabler of building microservices and deploying them with protability, speed, and at the same time reduces the cost. Containers are much more efficient than standard VM’s. You can run multiple containers on a single VM so that allows you to optimize the use of your existing VM infrastructure. However, you can run containers directly on bare metal without needing a traditional VM. This is highly efficient[GN1] . If you are a modern software company, you have already incoporated that culture into your delivery process. Teams want to see their work being used. It’s human nature. A modern software company has one to a few businesses, but they typically have hundreds or thousands of services running as part of a system. Their teams ship multiple times a day — at Amazon that’s 136,000 deploys per day, or roughly 1 per second! Modern companies like Google, Facebook, Twitter, Gilt, SoundCloud, have fewer systems with massive web scale. Speed is critical to adapt to disruptive shifts while empowering developers.
Remember, “Speed wins”.
So, Are you ready to win?
In my conversations with these large companies, I have heard a few times “I am not like Amazon, Google, Facebook, LinkedIn, or Twitter” so what they do does not apply to me. What they mean by it is that they may not have the web scale requirement of these modern companies. Even though a particular application or system may never reach the web scale of a modern software company, the shear diversity of the applications makes it even more challenging. You most certainly can deliver value at speed and scale (diversity) without sacrificing quality and need to if you care about time to market and competitive survival.
It’s not just about adopting new technology or tools for software development, it’s fundamentally about changing the culture of how you build software.
A few things to get you started
1.Containerize your monoliths. This will give you efficiency and portability. Efficiency will reduce your infrastructure costs as containers have smaller footprints than VM’s. Portability gives you the ability to move that workload to any IaaS (see #4).
2.Start by picking one feature that you can build as a small service and plug it back to the monolith by incrementally adopting microservices.
3. The software that you create should be treated as a valuable asset. So, like any other valuable asset, you want to have a system to track it, re-use it, share it, know how its being used, etc. Put them in a central repository system based on Git (Github, GitLab, etc).
4. Decide on the platform and infrastructure that will deploy and run your workload and look for features that enable and empower your teams to deliver to production easily and quickly while still optimizing the use of your distributed hardware and virtualized infrastructure.
All 4 can be done in parallel. For #2, it’s best to start off any new service in a source control system based on Git. The key here is that you don’t need to discuss for months on how to “re-architect” your application. It took SoundCloud 2+ years to decouple their Rails monolith. It may take you months or years to fully decouple and that’s OK — just start!.
It’s time to move beyond continuous integration and focus on the real issue of Continuous Delivery.
These would get you started on your journey to deliver value fast and you too can become a modern digital company. The reason you should care about adopting this culture of continuous delivery is because, hopefully, you care about maximizing value. The way to maximize value is to reduce cycle time. Guess what? That’s how you achieve your DevOps goal.
DevOps goal: Maximize Value
Thanks to Arun Jacob for some of the diagrams.
If you liked this, click the💚 below so other people will see this here on Medium.
