Improve Agility and Cost using Platform Engineering

“Enterprise IT” can be slow and expensive

Due to how Data Center operations work, most enterprises built a “cost efficient” operating centers. In some cases, it’s partly or completely outsourced. To make operations cost efficient, runbooks need to be well defined, and monitoring in place.

Whats the problem? Technology is changing so fast, that cost-efficient operators, trained to efficiently execute the well documented runbooks, cannot keep up, which leads to frustration of the operations team.

Engineering teams are asked to “update the runbooks”. Engineering scope is:

• Helping out Operations, 50% of their time
• Engineering, and keeping up to date with the last technology trends, 100% of their time
• 50% ever increasing technical depth, caused by this model.

200% of daily occupation leads to frustration of the engineering team.

But the greatest victim are the developers, in the endless loop of opening the Tickets to the Operations Team, and asking favors from Engineering Teams, just so they can do their work.

How do we break this dependencies-loop, and help our developers focus on the flow?

DevOps autonomous teams

Completely autonomous stream-aligned “product team” is a great idea, and it gives the developers the autonomy, and removes the blockers.

There are 2 problems with this approach:

• Independent team for each application can be expensive.
• We can’t really give the developers admin privileges to critical systems, such as Active Directory and Firewalls.

SRE (Site Reliability Engineering)

Google’s SRE approach advocates a Ninja SRE Team, that takes care of Common Tooling, and helps Stream-aligned teams work with SLOs and “error budgets”, a great way to manage the decisions using trade-off of new features vs uptime&security.

The problem with this approach is people. Both your Engineers and Operators won’t like the idea of you bringing an entirely new SRE team, and to become an SRE they need strong Software foundations, that take long time to “acquire”.

If we use Platform Engineering right, we can “have it all”:

• The best of DevOps (autonomous flow-oriented teams)
• The best of SRE (common tooling plus SLOs and error budgets)
• Happy transformation path for our Engineering and Operations teams

Imagine if we bring our Operators and Engineers into a single team. Instead of engineers creating runbooks, and operators executing them, the new team would focus 3 things:

1. Automate the Runbooks.
2. Turn the automated Runbooks into Self Service API, using the Automation Platform.
3. Expose the API using IDP (Internal Developer Platform), in a way thats logical for the user (developers).

The “3 wins” of Platform Engineering

We just created a Platform Team. There are 4 benefits of this approach:

1. Developer Autonomy: Developers now have more time to focus on features that bring most value to your business.
2. Happy Engineers: Your entire IT team will be happier, as their time will be better spent on creating value, rather then on long meetings trying to unblock the delayed implementations.
3. Cost: both Dev and Ops teams will spend more time on valuable work, and you will get more value, in Features, Security and Resiliency. All this translates to dollars.

Check out the summary video:

• ← Previous
Next →