Managing Infrastructure as a Product - Introduction to Platform Engineering

Kubernetes Community Days x OpenInfra Days Indonesia 2022
Managing Infrastructure as a
Product: Introduction to Platform
Engineering
Adityo Pratomo
Product Manager, GoTo Financial

Hi, I’m Didit
Currently managing Gopay.sh, our
homebrew internal developer tool
Used by 450+ engineers on a daily basis
Speed up our migration and
deployment effort
Accelerate ﬁxing compliance and
governance issues
Build from the ground up by and
utilizing various open source projects

Today, we’ll talk about
internal platform
📖 adityop.medium.com
⏱ Short history on how
we get here
🦸 Giving developers
super power
🏗 Managing
infrastructure as product

Short history, how we get here?

Some years ago…
��🏻💻
App
developer
��🏽
Network
engineer
��

Some years ago…
��🏻💻
App
developer
��🏽
Network
engineer
��
“It’s the network fault” “It’s the application issue”

Some years ago…
��🏻💻
App
developer
��🏽
Network
engineer
��
”Ah, so that’s where the problem is!”

Microservice is here
Embraced by enterprises and
startups to improve the
organization’s agility
Architectural decision that
represents organizational domain
and governance
Provides teams ability to move
independently and tackle each
domain’s issue

DevOps as the enabler
For teams to truly achieve
independence, they have to be
able to fully own the end-to-end
process of building and operating
services
“You build it, you own it”

However…
Building AND operating service are 2
vastly different domain and problems
Both requires different set of skills,
stemming from different background
with different practices as well
It become a tall order if we want
developers to be able to operate their
own services
Remedied through manual process ✅

The problem
- Not scalable
- Repetitive
- Back to square one
��🏻💻
App
developer
��
DevOps
engineer
��

The problem
I build it, but do I own it?

The solution
Codify the practice to operate the
services, so developers can do it on
their own
Provide manual intervention only for
edge cases
Exposes abstractions over the
underlying infrastructure to make it
more developer friendly
We call this platform

Giving developers super powers

Ensuring platform gives values
Platform is a wide domain and
building it would be very contextual
for every organization,
A uniform goal: improving developer
productivity
To ensure it’ll be successful, let’s step
back and see developers’ workﬂow.

Modelling developer activity
1. Discover: gathering information
required to start writing code
2. Build: translating requirements into
code
3. Test: testing the recently written code to
ensure that it ﬁts the requirement
4. Integrate: build and deploy the code, to
make it integrated with the wider
system
5. Verify: testing the recently integrated
code, to ensure the functionality
correctness

Improving developer activity
The key value of a developer is realized in
write and test steps, these are the main
productive time
Improving developer productivity can be
started by reducing the time spent by
developers to do discover, integrate, and
verify steps
That’s where our platform can play
fundamental part.

As an example
let’s tackle point 4.
help developer in speed up the process of
deploying the code to our underlying
- freeing developers from writing brittle
YAML ﬁle?
- veriﬁcation that the process works?
- feedback so they can act accordingly?
- utilize a graphical UI to give additional
information?

We know the problem, but
solution can go either way
Whichever solution we choose, it could work,
but now, you can imagine the subsequent
complexity
Now we’re exploring the solution space, but
even after we make our choice, we need to
validate the solution
This is where product thinking can help

Managing infrastructure as
product

Platform is a product
we shifted platform from a one and done foundational
layer to malleable product that we can iteratively craft
it becomes imperative for us, as the builder to think of:
● what are the business outcome that we want to
address?
● what are the pain points that the developers are
experiencing?
● how big is the problem?
● can we validate that what we provide the desired
solution?
● what to prioritize next?
Infrastructure
Platform

Product thinking
Product thinking helps us see things in 3 different
lenses:
- Business (viability)
- Technical (feasibility)
- User (desirability)
You can say that product management is the bridge
that connects these 3 islands

Feasibility
The underlying layer itself is already taking shape in
form of higher level abstraction (e.g. Kubernetes, Istio)
over lower level building block (e.g. OS).
Exposing bare Kubernetes or Istio to developer, isn’t the
correct strategy since each has its own complexity
Utilize their APIs to create more valuable abstraction and
automation that empowers developers to operate their
services.

Desirability
Aimed towards experts
Feature wise, the product will go deep and focused
towards speciﬁc domains
highly contextual to how the company is organized and
governed
✅ Identify the current workﬂow -> map it -> systemize it
via platform -> gradually optimize it
✅ provide better UX on each iteration

Example
As a developer, I want to be able to deploy my
services to our Kubernetes cluster without
having to write YAML conﬁguration from
scratch, so I can conﬁdently complete it
myself
Solution through GitOps and Kubernetes
friendly CD provider. Deployment is 1 trigger
away, platform provides the pipeline template
March sprint

Example
myself
❗developers still feel that sometime, they
have to do context switching between
platform and CD provider to ensure
successful deployment
March sprint

Example
myself
❗developers still feel that sometime, they
have to do context switching between
platform and CD provider to ensure
successful deployment
As a developer, I want to be able to check my
deployment status straight from the platform,
so I can verify without having to do any
context switching
March sprint
May sprint

Viability
Business outcomes will also move over time, even if it’s
not that often
Example of desired outcomes:
- Reducing infrastructure cost by 10% at the end of
2022
- New joiners can deploy to production within the
ﬁrst week of joining
- 100% services adhere to the regulatory compliance

Eventually, the
platform evolves
The platform
should evolve
guided by the
lenses.
It’s a living
product

So we need to
create direction
Product vision: to improve developer
efﬁciency inside organization
Goal: reduce time to
complete deployment
Goal: reduce number of
issues related to
deprecated libraries
Goal: reduce average
time to resolve incidents

In the end
��🏻💻
App developers use
it to operate services
��🏽
DevOps engineers provide both
infra and its abstractions
��
��
��
��

To summarize
Platform enables DevOps culture
Platform needs to be crafted to solve speciﬁc developer pain points ﬁrst,
before tackling another
Platform will evolve and we need to manage it as a product

Thank You
Let’s Connect
@kotakmakan
adityop.medium.com

Managing Infrastructure as a Product - Introduction to Platform Engineering

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Managing Infrastructure as a Product - Introduction to Platform Engineering

Ähnlich wie Managing Infrastructure as a Product - Introduction to Platform Engineering (20)

Mehr von Adityo Pratomo

Mehr von Adityo Pratomo (11)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Managing Infrastructure as a Product - Introduction to Platform Engineering