DevOps vs. SRE vs. Platform Engineering (Clickbait!)
Michael Franz Heiss
Strategic empowerment of leaders and product teams in digital strategy, portfolio transformation, organizational design, product management, platform strategy, platform engineering, Cloud/IT architecture, and DevOps
There are many discussions about ???????????? ????. ?????? ????. ???????????????? ??????????????????????.
Here is my attempt to provide some links and my personal interpretation about those concepts.
It was planned as a normal social media post, but became too long (number of characters) to post it. So please excuse any spelling errors and grammatical mistakes in this post.
????????????????????: ?????????? ?????????????????????? ?????? ?????????? ???????????? ???? ???????????????? ??????????????, ???????????????????? ??????????????????, ????-?????????????????? ?????? ??????????-??????-????????????????. ?????? ???????? ?????????? ?????? ????????????????, ??????????? :) ???? ?????????? ???????? ?????????? ???? ?????????????? ???? ???????????? ???????????????????? ?????? ?????????? ????????????????. ???????? ???????????????? ????????????????????/???????????????????????? ?????????? ?????? "??????????????" ???? ???????? ???? ???? ?????????????? ??????????, ???????? ???? ?????? ???????????????? ?????????????????? ???????????? ???? ???????? ??????????????????... ?????????? ???????? ???? ?????????? ?? ???????????? ???????????????????? ?????? ?????????? ????????????! ?????? ???????? ???? ???? ???????????????? ?????????? ?????????????? ???????? ?????????? ???? ???????? :)
DevOps (Organization-level, Culture, Behavior)
Links:
It's about organization-wide change of behavior (management, crosscutting departments, Dev and Ops). It's about collaboration (e.g. start to talk with each other and getting rid of bad silos and stubborn tayloristic processes). It puts more focus on quality, learning, automation, feedback, lean principles, autonomy/shared responsibility, constant value delivery and turnaround capabilities in case of critical situations.
DevOps is not a set of tools or practical guidelines. It's an idea, revolution, mindset, culture, behavior fighting the not-so-well-working mistakes of "scientific management" and "taylorism" in organizations with IT-based products/services.
The promise is to create sustainable social systems (happy engineering teams, work-life balance despite of developing/operating 24/7 services, low fluctuation, full commitment to business goals and customer value) and good quality technical systems (efficiency and effectivity at the same time). Happy cows and a constant stream of high quality milk.
DevOps will not work in companies that rely on exploitation of human beings. I saw those initiatives fail at car vendors and large banks. There's no way to achieve the pros of DevOps without starting to listen to your employees needs and get rid of narcissistic management behavior.
DevOps is not needed in organizations that never tried to apply Scientific Management principles in their IT-departments. That's why startups usually don't have to deal with DevOps. They just hire fresh blood from universities or people that never experienced being trapped in a tayloristic cage.
Still DevOps is a great starting point to get organizations with "history" into the discussion about how they can do "business" or provide "digital services" in the future. And there a thousands of good case studies, reports, videos, books to learn about how to get there.
Continuous Delivery / CD
Links:
(Follow Dave Farley and Bryan Finster on Twitter, LinkedIn, Youtube)
It's what engineering teams should do from a practical perspective. No matter if there's a "DevOps initiative" in your organization or not.
“Continuous delivery improves both delivery performance and quality, and also helps improve culture and reduce burnout and deployment pain.” (quote from minimumCD).
Read minimumCD for more details :)
领英推荐
"You build it, you run it"
Link:
To me it's a style of DevOps, saying that people who build software should also run/fix/operate it. It's about responsibility. It usually involves CD. It fits perfectly to "digital services" and "product teams" that develop their own service-based products.
But dear "You build it you run it"-Cultists, be aware that there is still need for separation of Dev and Ops in some organizations. E.g. public sector organizations because of lack of Dev people. Or when you need to operate mostly 3rd party software/infrastructure. Whenever your ops teams are conformists, adopting SRE principles to make sure that 3rd parties don't accidentally break your stuff is a good idea!
Site Reliability Engineering (SRE)
To me it's a style of DevOps, putting more focus on Ops work. SRE follows similar goals and principles like DevOps.
It's often applied when operating 3rd party software or running custom-built solutions that have been produced by external development contractors. SRE provides good ideas to run critical software (e.g. banking, e-government, education) and critical infrastructure (databases, gateways, cloud platforms etc).
There's usually not much "you build it" despite glueing components together. A big focus is on doing changes on these components (new versions, new configuration) without breaking stuff. SRE can be done without learning SRE jargon (SLO, SLI, etc.). I know a lot of teams who do exactly the same and started doing it before SRE was a thing.
Platform Engineering
Link:
Because Product Teams often have T-shaped skillsets, they lack technical capabilities to integrate complex technology and don't have time to deal with legacy worlds (ITIL operations, Governance units, custom-built protocols, etc.).
Platform teams focus on establishing self-services (lego bricks) to reduce technical / organizational complexity for anyone that needs to use it. A platform team is basically enforcing the "Shift Left". They are handling conversations with departments/silos that don't want or can not change their way of doing things (classic business IT, vendors, cloud providers).
A platform is a marketplace where providers (classic it, datacenter services, legacy systems) interact with consumers (product teams, business partners, etc.). The product of a platform team is often called "Developer Platform", "Cloud Platform", "DevOps Platform", "API Platform" etc.
Platform engineering usually involves adopting several concepts like DevOps, CD, SRE, "you build it you run it" and interacting with teams that may have also adopted some of those concepts.
Summary
No summary... This should've been a social media post, but was too long to post it directly.
Strategic empowerment of leaders and product teams in digital strategy, portfolio transformation, organizational design, product management, platform strategy, platform engineering, Cloud/IT architecture, and DevOps
2 年In the next episode I'll add "FinOps" ...Just to scare everyone with stuff that will take probably at least 5-10 years for mainstream adoption :D
Cloud Architecture & Engineering, Integration Specialist
2 年Nice write up. As we more compose solutions from bricks than build from scratch we need more ops and more pipelines.