One of my sisters is a veterinarian, she has a degree in animal husbandry. Her job is stressful and tough, both from a patient perspective as well as their owners. She loves animals and hates to see them abused or in pain. She is often confronted with owners who either don’t care or can’t afford to properly care for their pets. This leads to some trying to euthanize their pets for minor health issues because they never thought about the long term care costs.
Now before you assume that my next comment is saying we should look at human care the same way, please remember this is primarily an IT blog.
Many of you have heard me or someone else expound on the Platforms of Applications that IDC laid out P1 through P3 apps, and the analogy of P2 & P3 apps being like pets and livestock. If not here is a quick synopsis (for those of you who are familiar please read ahead):
Platform 2 applications are the many of the X86 apps we run today, SharePoint, Exchange, SQL Server, Oracle, etc. These applications all require care and feeding, but if we want more from them then we need to grow them vertically. Meaning more app servers running the same applications and clusters or split resources. These sorts of application trade offs are fine and expected, and in fact the app owners tend to care for the apps as though they are part of their family, polishing the server bezels and spouting things like “Precious!” They are also the ones who are quick to blame infrastructure teams for their apps failings when service interruptions occur because redundancy is tied directly to the environment it sits on.
P3 apps are built in micro services, hopefully meaning the 12 Factor Manifesto was 
followed, but here we find that the applications are groups of services that link together to create a mesh. Applications scale horizontally and single service failures do not impact the overall application availability. Here applications are more tied to the platform and code that creates them, and are far more flexible. *NOTE: This is not to be confused with containers. Micro Services != Containers
Application owners by and large don’t realize the impact or plan for the long term lifecycle of an application. More importantly application development teams don’t make those considerations either. This leads to conflicting views when application lifecycles are discussed. Much like an actual pet you have preventative care and maintenance to keep both you and the pet happy. Your Operations staff act as your Vet here and help to direct and mitigate any pain. With livestock you have the option to cull the herd, and eliminate bad or unsavory elements. Microservices act in the same way allowing you to kill services, perform continuous release cycles of code and change on the fly. Try doing a code update on SAP during working hours, I dare ya. The CMDB board would be on you faster than, me exiting to a Krispy Kreme when the Hot and Fresh sign blinks on.
This isn’t to say that all P2 apps are bad, or that all P3 apps are good. In fact there is debate around the Megalith vs Micro Service approach all over the interwebs. But it’s important to understand the difference.
Oh and containers … next post I promise.
30 blog posts in 30 days. If nothing else this will stretch my limits of writing and hopefully won’t drive me crazy like Jack in The Shining.
they don’t know where to begin to select a solution. I thought about responding duh depends on your workload but I stopped and thought you know maybe I am approaching this wrong.
That’s the worst sales pitch ever, but if you live in the country and only have a few choices of where to eat this makes a lot more sense. Try to tell your wife date night is at a bad restaurant and tell me I am wrong. In the end picking storage with workloads in mind and data protection requirements is still a key ingredient to success, just like agreeing with your SO on where to go for dinner