DevOps is about teams of developers and operations specialists breaking down department barriers to work together more efficiently. Using and adopting the DevOps philosophy requires a new mindset, new tools, and a new set of skills. One way to think about why DevOps is such a brilliant innovation is to imagine an emergency room where all the physical areas, staff roles, institutional functions and so on can continually morph and transform into their most useful forms.
Take a look at this diagram of an emergency room. The first three parts illustrate the check-in process. The fourth part shows the triage function, where emergency room staff will determine how serious your situation is (if it needs to be addressed right away, or can wait). The fifth part indicates the check-up with the doctor. The sixth part indicates the end of the doctor’s check, where you get a treatment protocol and/or prescription. Finally, the last part indicates the back office, where you settle documents and balances before you check out. The whole point is that there are multiple people working across these resources, much like a server.
Using this analogy, think of this setup as a server with a fixed number of resources. The doctor here is probably the most precious resource the emergency room has, and they get the busiest. If a particular group gets really busy, why not free up resources from these other groups? Instead of having fixed real estate dedicated to a surgery room in the event that nobody is getting checked in, then you turn that down and create more surgery rooms. You get to handle the backlog and move patients through this process much more quickly. When surgery is quiet but reception is busy, you transform the surgery rooms into more reception space. If your assets within an emergency room are fungible, and you could shift assets back and forth, you could have a much more efficient operating environment.
An emergency room will only work as efficiently as its least efficient part, and that is why managing applications is like running an emergency room. However, that is the old application model.
Today, instead of having one giant monolithic application, what you can do is break down the application into discreet services. Since they have been broken down into discrete components, you can give the developers the luxury of working on each piece independently. You can upgrade the database without worrying about other components. This means you can unshackle as an organization, and move much faster, with application developers working together. Your team can focus on where the attention is needed. This is why DevOps has taken off: the ability to break down the application into smaller, discrete services frees up so much energy and capacity for an organization.
In the DevOps world, since everything is software, if a front office gets packed up, you can use all of these resources in a fungible way. You can mix components, shut down some groups, and mix resources among other groups as your workflow moves through. Using this system, you can focus on the type of service that’s needed the most at that moment in the emergency room.
For example: here we have a bunch of different services or workloads running per OS. The workloads are color coded, and if this were an emergency room and there is no need for some of them, you can simply turn them off. Basically, if you could repurpose resources using this model, then it would become a much for streamlined operation.
The main goal of DevOps is to improve reliability and provide faster development and deployment cycles. Many of the ideas (and people) involved in DevOps came from enterprise systems management and agile software development movements. Overall, DevOps was created to improve the system as it helps in reducing the amount of manual work required. To learn more about DevOps and Microservices, read our blog here.