Luca and Falko are joined by Isaac Perez, Head of Infrastructure at Fresha.
They discuss how to put together a strategy for the ever expanding responsibilities of devops/platform/infrastructure and all the areas that can fall under.
Questions discussed include the following:
- What does the evolution of a traditional Infra / DevOps team to a modern one look like?
- How do you show business impact of invisible work?
- How do you modernise your strategy with old people?
- How do you actively plan for the future, instead of being ambushed by it?
In this episode, Isaac Perez, head of infrastructure at Fresha, delves into the intricacies of creating and implementing an infrastructure strategy within the DevOps framework. He highlights the evolution from traditional operations to an agile, user-centric approach that aligns with modern software development practices. Perez underscores the significance of considering both technology and business objectives, while also focusing on improving developer experiences and service stability. He shares insights on enabling teams, dealing with distractions, and optimizing infrastructure decisions to support business growth and efficiency.
Inhalt
- Introduction of Isaac Perez and his role at Fresha
- The evolving role of infrastructure in DevOps
- The significance of infrastructure strategy
- The shift from traditional operations to agile methodologies
- Integrating developer experiences with operational efficiency
- The impact of infrastructure decisions on business outcomes
- Challenges in balancing technology advancements and business needs
- Role of microservices and platform stability in business growth
- The importance of enabling teams and handling distractions
- Infrastructure strategy’s influence on organizational structure
- Recommendations for creating an effective infrastructure strategy
- The role of microfeedback loops and efficiency in DevOps
Shownotes
Isaac’s Medium posts
Isaac’s LinkedIn
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
Welcome to a new episode of DevOps auf die Ohren und ins Hirn.
Or in English, DevOps from your ears straight to your brain.
Usually this is a German language podcast, but we sometimes make exceptions for international guests.
Today is one such exception.
My name is Luca Ingianni and I host this podcast together with my colleagues Dirk Sölner and Falco Werner.
We’re DevOps consultants, trainers and coaches trying to get teams to work together better and create better products for their customers.
And today we are joined by a very wonderful guest, Isaac Perez, the head of infrastructure at Fresha.
Isaac, very welcome to the show.
Thank you. Thank you for having me, Luca and Falco.
Tell us a little bit about yourself, Isaac. What do you do for a living?
I lead the infrastructure teams at Fresha, which is a beauty and wellness platform.
It’s actually two-sided. We have the marketplace where you can book your appointment in a hair salon or nails or a massage or spa.
And we have the business management platform that allow those businesses to do everything that they need to run their business,
manage the rotation of the staff, sell products, marketing campaigns, book appointments, take payments.
And anything that you need, really.
The main areas of the teams that I lead, which are part of the platform organization, are focused on cloud infrastructure.
So traditional, where you run your workloads for us, AWS and EKS mainly.
And the other parts are deployment pipelines and developer experience.
So how we can get that software development cycle shorter and have a better user experience.
My background is in systems administration, data center operations, then DevOps, then platforms.
So it’s kind of the evolution of the space as it went through the years.
Yes. And the topic that we have picked for today is infrastructure strategy, isn’t it?
Yes.
So this is something that I’m very curious about.
How to sort of deliberately create a strategy to evolve your infrastructure and the people operating it,
as opposed to being…
Stuck in a reactive mode and sort of trying to muddle through.
Okay. But before we dive into the topic, we have a tradition on this podcast for every guest to give us their definition of DevOps.
So, Isaac, what’s your definition?
That’s an interesting one, because it seems that everyone has a different definition and a different implementation.
To me, I started seeing it from one point, which was bringing…
Software development practices to operations teams.
Traditionally, operations teams were at most scripting and not necessarily like having a software lifecycle for their tooling,
like not treating their services, their outputs as a real service where you have to test it, deploy it.
So that was the initial part.
But then I realized that it has another component, which is before, like many years ago,
like development teams would throw things over the wall, as we say, and operations teams would have to run and deploy the changes or the new features that the software delivery teams did.
But that was the usual complaint.
But I also realized that operations teams used to do the same.
So we used to build a tool, whatever we wanted, and then tell all developers, now you use this.
Like, we don’t care what you think.
We don’t care about the user experience.
You’re just going to use it.
And that caused frictions.
Both ways.
So I think DevOps is bringing two walls closer together in the sense that operations do more software development, more agile and more user experience.
But at the same time, development teams also learn how to run their services.
They own them now.
In theory, they own them or they should own them.
They got better at productionizing those services and maintaining them and making them operationally excellent.
Which was not something that software product teams were good at or were not good.
Like, it was not one of the goals for them.
It was just ship features.
And now it seems that both walls got a bit of each other.
And to me, that’s a better outcome than the silos.
Okay.
And where is testing in this?
That’s a good question.
To me, testing, I see it as kind of a platform offering.
So the platform team.
The team should provide the tools to do testing, like tooling services, like build a framework and the software teams should do the testing because they know that their software better.
So I think they should be able to run, create better tests and it goes earlier in the in the cycle, but with that with some help because the testing mentality is a bit different from software mentality when they test a lot.
Think about edge cases and load.
And all that, but I still think it’s better if most of the testing happens early in the cycle like TDD and done by software engineers with the help of some either coaching and tooling and platform services provided by really real experts also doesn’t scale if it’s not distributed.
You cannot have like one tester or one QA or a team that ends being the bottleneck for everything that’s deployed that reduces.
You cannot have one tester or one QA or a team that ends being the bottleneck for everything that’s deployed that reduces.
Makes the deployment times or recycle time much, much longer.
After operations, is there something that you need to consider in the value stream that’s after the operations teams or the infrastructure?
That’s a good question.
I would say the product team, right?
After that, you need to ensure that the features that you deliver.
Well, there’s two dimensions.
One is that the features actually produced an outcome from the business that they’re not, I don’t know, we just shipped a feature, doesn’t provide anything.
And then that you can continuously maintain and evolve that feature.
So one would be more technical in the terms of like, can we maintain, can we evolve this feature?
Do we have the metrics to know from an operational point of view that’s working well?
But also do we have the metrics to know that from a business point of view, it’s working well, it’s worth it?
Is it worth the cost?
How’s your connection to the customer then?
My connection to the customer, it depends.
These are another interesting question because usually I have a very personal distinction between users and customers.
To me, in the platform world where I sit in infrastructure or DevOps or platform, users are usually software engineers.
Who use the tools that we build.
But they’re not our customers because they don’t pay our salaries.
Our customers are the end customers that buy the products that the company sell.
And at the end of the day, those are the important ones.
So our users or software engineers are just a proxy to reach the customers.
Sometimes, most times, they both align.
So we create better pipelines, better developer experience, so we can get more features out and more stable features out to the customers.
But sometimes we may do some security work that actually hinders a bit the developers, but it’s to protect the customers.
Maybe we do some high availability work that hinders the developers, but protects the customers.
So at the end of the day, the customers, the ones who pay, are the ones we serve.
And most of the time we do it through our users who are the software engineers.
All right.
So maybe now is a good time to switch gears.
And I’m going to ask you a question.
And take a step back and set the stage for what we want to talk about, which is infrastructure strategy, right?
Why do we need that?
And did we have that before?
And what does it look like?
What did it look like?
I mean, you spoke in the introduction a bit about this separation between dev and ops, you know, the famous wall of confusion.
Was that part of a strategy or was that just an accident?
That probably was a result of the environment.
I wouldn’t call it an environment.
I wouldn’t call it an accident or a strategy.
I’m pretty sure it was not part of a strategy, because when you think about it, it seems a pretty bad strategy to have.
It’s like, let’s get operations and developers not talking to each other so they cannot work together and we release worse features less often.
So that as a strategy seems something no one will come out with.
But that was the result.
So I think it was a product of the time where Agile was.
It was probably still coming.
Well, it didn’t even exist before.
It was very waterfall of planning and you had two different sections and they have their different waterfall processes and Agile started catching up, but operations was behind.
So I think that the strategy was always there.
It just didn’t caught up with the times or with the modern practices and people at the strategic level were not thinking, updating.
They were not thinking, updating.
They were not thinking, updating.
There’s a way of thinking about the strategy, a way of thinking about technology or engineering in a modern way.
They were just the old waterfall process.
This is my turf.
This is your turf.
Don’t touch it.
We’ll talk at the end kind of thing.
And I think it makes sense from the point of view that strategies are usually created by senior people who most of the time are older and they’re setting their ways.
Well, I’m saying that I’m not that young, but I think that because they were created by an older generation, it took some time until the new generation who were more in Agile and had a more open mind, at least to that point, started creating the strategies themselves and they realized, okay, this doesn’t make sense.
We’re going to get better outcomes if we work together and then started being part of the new class of strategies, if you want, of the new strategies that were being created.
Okay, so now we do need a strategy.
What is, what’s the point of this strategy?
What are the cornerstones of the strategy?
What does the strategy aim at versus what maybe does it explicitly say, this is out of scope for me?
Yeah, that’s the always problematic point when you start a strategy, like what do you want the strategy to do?
What is the strategy for?
And I think this is where…
Most, not most, but hard for business leaders or like engineering leaders, especially in infrastructure, you’re quite removed from the business and sometimes we forget about the business part and we’re just like, we need to use Kubernetes or we need to use like, and really no one cares if you use Kubernetes or not.
Like you think like they have salons care if we run in AWS and Kubernetes, no, they don’t.
They care about the reliability of the product, how fast the features are.
Arriving at their terminals, at their like fonts.
So the strategy should really understand what is the problem we’re going to solve for the business.
It can be a technological problem, but it has to help the business.
And where was the environment?
So I would not do, and I certainly did different strategy in smaller startups than a scale up like Fresha.
They’re different than bigger companies they work for like Thomson Reuters, we have like 5,000 people in the…
Business unit that I was working in.
And so the strategy not only has to take into account the problems that you want to solve for the business, not for technology itself, but also the environment where it works.
Not the same is a highly regulated industry.
It is not.
It’s like it doesn’t matter if you lose the data for like one hour.
It’s like those kind of things should guide the strategy too.
Okay.
So what is the point of the strategy?
What is the goal of such a strategy?
Or what happens if you don’t have such a strategy?
So, okay, those two different, let me see if I can split them.
The goal of the strategy, it has to be to help the business reach its goals.
So let’s say that you’re in growth mode, like hyper growth mode, and you need more users per month, more active users per month, which is usually like a common goal for growth companies.
Then how do you get those users?
And do…
How do you get and how do you lose these users?
Something I like from system thinking is when you have a stock, you can fill…
Let’s say you have a bathtub, you fill water and you have the drain.
So you can fill the bathtub, you can put more water faster than it drains or stop the drain.
So when you have more active users, I say you want more active users, you get new users, but users leave.
And more users, let’s say that you need more features.
And users leaving is because the platform is not stable.
So they get frustrated and they leave.
And simple examples.
And what we can do as a strategy from infrastructure in that sense will be less work on having deployments to production faster or short and feedback loops for developers.
Those two common things that are usually painful and people always want deployment from, you could make a change to it’s running in production faster.
So you could work on that or you could say, actually we’re losing lots of users because the platform is not stable.
Because the platform is not stable.
Die Plattform ist wirklich unstabil und wir müssen ein paar Arbeiten machen, um die Kette zu stabilisieren.
Und das ist wichtiger, als mehr Features zu haben.
Wir können sagen, eine kurze Strategie, um die Stabilität zu fixieren, damit wir die User nicht verlieren.
Und eine langfristige Strategie, wir wollen mehr Features erstellen.
Die Stabilität ist auf einem guten Niveau.
Okay, aber das klingt immer noch wie eine Produktstrategie, nicht so viel wie eine Infrastrukturstrategie, richtig?
Ja, aber die lustige Sache ist, dass wir die Infrastruktur als Produkt behandeln sollten.
Wir sollten es nicht selbst machen.
Zumindest glaube ich das.
Unsere Infrastrukturstrategie sollte nicht so anders sein wie die Produktstrategie.
Was sich ändert, ist, wie wir sie implementieren.
Zum Beispiel könnte eine Produktstrategie sein, dass wir diese neue Feature eröffnen,
die euch ermöglicht, Abonnenten zu buchen,
ich weiß nicht,
von eurem Handy.
Weil wir das vorher nicht gemacht haben, was auf der Website war.
Und von der Infrastrukturstrategie her könnten wir sagen,
wir müssen eine Deploying Pipeline für Mobiltelefone erstellen,
weil wir keine vorher hatten.
Und es hat drei Tage oder fünf Tage gedauert, um zu bauen, zu kompilen, zu publizieren und alles.
Also unsere Strategie für die Infrastruktur wird das Geschäftsziel in einer anderen Weise unterstützen.
Und vielleicht ist es, um euch ein Beispiel zu geben, ein bisschen mehr Infrastruktur.
Und ein Projekt, das wir momentan arbeiten, ist das Migration von Jenkins und anderen
Arbeitsplattformen zu Argo Workflows.
Warum denken wir, dass das wichtig ist?
Ich denke, weil sie diese zwei Bereiche entwickeln, mehr Dimensionen zu diesem.
Aber zwei wichtige sind die Entwicklungserfahrung und die Entwicklungserfahrung.
Also die Erfahrung, die die Entwickler haben,
und die Entwicklung der Deploying Pipelines,
mit denen wir denken, dass es in Argo Workflows viel besser werden wird.
Und unsere eigene Erfahrung in der Entwicklung der Pipelines,
die viel, viel schneller werden wird als in Jenkins,
weil es viel einfacher zu arbeiten ist, es ist einfacher zu testen und so weiter.
Also die Art und Weise, wie wir die Geschäftsstrategie halten,
wäre langfristig, wir migrieren zu einem Cloud Native Workflow Engine,
das kosteneffektiv sein wird,
viel schneller zu arbeiten,
und viel schneller zu entwickeln.
Aber das klingt immer noch reaktiv für mich, richtig?
Du hörst auf die Anmerkungen der Entwickler, was eine gute Sache ist,
nicht wahr?
Aber es ist nicht proaktiv, ist es nicht?
Du wirst nur warten, bis du die meisten Anmerkungen bekommst,
und dann gehst du und fixierst es.
Ja, ja und nein.
Wir, zum Beispiel, können,
wenn du nur die Anmerkungen hörst,
hast du Jenkins fixiert.
In diesem Fall zum Beispiel.
Aber ich denke, die Strategie kommt dazu,
das Problem zu sehen,
dass es bessere Deployment Pipelines gibt,
und dann zu denken, okay,
wir gehen zu Cloud Native Tooling,
oder wir gehen immer noch zu Cloud Native Tooling.
Jenkins, zum Beispiel, ist zwei Generationen alt,
wir wollen etwas, das Cloud Native ist,
für diese Gründe,
was kosteneffektiv ist,
einfach zu arbeiten,
einfach zu unterstützen,
weil wir bereits viel Erfahrung in Kubernetes haben,
und das funktioniert in Kubernetes,
also denke ich, es ist ein bisschen mehr,
es ist das Hören zu diesen Anmerkungen,
aber auch gleichzeitig,
du wirst deine Plattform weiterentwickeln,
in Richtung eines Zukunfts,
das sich mehr mit,
also du wirst die Plattform weiterentwickeln,
in Richtung einer flexibleren und nachhaltigeren Lösung,
die dir ermöglicht,
in der Zukunft schneller zu gehen.
Also vielleicht fragst du dich,
etwas, das wir gemacht haben,
ohne zu hören,
zu User Complaints zu Beginn.
Und das ist,
ich habe noch ein anderes Beispiel,
wir haben begonnen, Backstage zu nutzen.
Was ist Backstage?
Ich habe das noch nie gehört.
Okay, das ist eine interne Entwicklungsplattform.
Es wurde intern geschaffen,
Spotify hat es geschaffen,
sie haben es open source gemacht,
und es ist irgendwie das Standard,
open source,
eine interne Entwicklungsplattform.
Und wir haben mit Kit angefangen,
weil wir wussten,
wir haben einige Schmerzpunkte,
wie z.B.
finden Sie Ihre Services.
Wir haben begonnen,
mit Microservices zu migrieren,
und jetzt haben wir etwa 80
zwischen Monolith und Microservices.
Und es ist sehr schwierig,
eine neue zu erstellen.
Und es ist sehr schwierig,
die Services zu finden,
die sie besitzen.
Wir haben Splitsheets,
und du musst durch den Code gehen.
Also Backstage hat das Problem gelöst,
plus es ist ein weiteres Tool,
das, sobald wir einen Fuß in das Tool haben,
es wird uns ermöglichen,
viel mehr Sichtbarkeit und Fähigkeiten zu bieten.
Und das kam,
teilweise aus Schmerzen von Entwicklern,
aber es war okay,
wir sehen,
interne Entwicklungsplattformen
werden in der Zukunft wichtig sein,
also wollen wir in sie investieren.
Und wir haben mit Kit angefangen.
Und das ist eine Art Stepping Stone
zu einer Plattform-Team,
einer Plattform-Organisation,
anstatt der traditionellen Infrastruktur,
wo wir etwas bauen und es nutzen.
Interessant, ja, danke.
Das war ein sehr gutes Beispiel.
Aber es bringt mich zu etwas anderes,
was mich bedroht hat,
nämlich dass du selbst gesagt hast,
dass die Beauticianen
oder jeder, der deine Plattform nutzt,
nicht wirklich interessiert,
ob du Backstage oder Kubernetes
oder irgendwelche dieser lustigen Dinge nutztest.
Also, ich meine,
und ich stimme dazu,
dass dies wahrscheinlich wertvoll ist,
aber wie kannst du Business-Impact zeigen?
Wie kannst du Wert für solch unbeleuchtetes Werk zeigen?
Ja, das ist ein guter Punkt.
Und es kommt alles zu,
aus meiner Sicht,
Metriken,
über die das Unternehmen sich interessiert.
Also z.B. für Backstage
eine der Metriken,
die wir verbessern wollen,
ist Onboarding.
Also sagen wir,
dass du 50 Entwickler im Jahr hast
und anstatt Onboarding,
hast du für 4 Wochen
mehr als für 2 Wochen,
weil sie alle Dokumentationen finden.
Das sind 50 pro 2 Wochen,
du bekommst 100 Wochen Produktivität pro Jahr.
Also das ist sehr einfach
für das Unternehmen zu zeigen,
wie wir 100 Wochen Produktivität
zum Ingenieur-Team hinbekommen.
Und das Gleiche
mit täglichen Aufgaben.
Es ist nicht so einfach,
nicht so einfach zu sagen,
wir bekommen etwa 2 Tage mehr
oder so etwas wie das,
aber wir können Metriken haben,
z.B. wenn es User-Surveys sind.
Wie lange dauert es,
um einen Service zu finden,
mit dem du arbeiten musst?
Die Dokumentation,
die Anwohner.
Also vorher
dauerte es vielleicht ein paar Stunden,
bevor du an einem Ticket startest.
Jetzt dauert es 5 Minuten.
Also das sind die Metriken,
die du nutzen kannst,
um Impakt zu zeigen.
Und im Backstage
sind die meisten Metriken
zu dem,
wie lange es dauert,
um etwas für einen Entwickler zu machen,
als jetzt.
Ein weiteres gutes Beispiel ist,
dass wir uns in Richtung
der Migration
zu Microservices
und der Extraktion
des Monoliths
bewegen.
Das ist ein sehr neues Problem,
das noch niemand
vorher hatte.
Und das war eine Lüge.
Ich dachte,
ihr würdet…
Keine Ahnung.
Also,
es ist nicht einfach,
einen neuen Service zu erstellen,
ohne das Tool zu haben.
Aber das erste,
was wir mit Backstage gemacht haben,
war,
Service-Template zu nutzen,
also,
ihr klickt
und bevor es euch 2 Wochen dauerte,
um einen neuen Service zu erstellen,
im Allgemeinen.
Jetzt dauert es,
ich denke,
jetzt sind es ein paar Stunden.
Es ist nicht
Zero-Zeit,
aber
ihr ging von 2 Wochen,
also,
sagen wir,
ihr plant
diese neue Feature,
wir brauchen
einen neuen Service,
denn wir wollen
zu Microservices
migrieren
und das hat andere Vorteile.
Wir planen
4 Wochen
oder 6 Wochen,
weil die ersten 2
mussten wir
nicht haben,
den Service.
Und jetzt
sind diese 2 Wochen
weg.
Ja,
wir werden es machen.
Es sind nur 2 Stunden,
also müssen wir nicht
so viel für es zahlen.
Also,
ihr verringert
die Migration
aus
der Monolith,
was
alle
Kaskadeneffekte
oder
schnelleres Entwicklung
bringt.
Aber ihr entfernt
essentiell 2 Wochen Arbeit,
jedes Mal,
dass ihr das macht.
Und ich denke,
das sind die Metriken,
die das Unternehmen
interessiert.
Und
sie sind,
sie sind super cool.
Du musst ihnen sagen,
schau,
es hat 2 Wochen gedauert,
um ein Service zu schaffen,
jetzt dauert es 2 Stunden.
Und vielleicht in einem Monat,
wenn wir mehr investieren wollen,
dauert es 0.
Weil alles
automatisiert wird.
Nicht nur das,
der Service kommt
mit
90% Produktion,
was wir als
Produktion bereit
bezeichnen,
das ist
ein weiteres Monat Arbeit,
das die Entwickler
tun müssen.
Das bringt mich
zu einem interessanten
Frage,
das ich
während
deiner Rede
beantwortet habe,
dass es
so eine Strategie
Formulierung
gibt,
wie würde es Teil
deiner Strategie sein,
zu sagen,
wir werden
zurückgebracht
oder wird
die Strategie Formulation
auf einem hohen Niveau sein,
wo wir sagen,
oh,
wir müssen
Wege finden,
um den Zeitraum
für einen neuen Service
zu reduzieren,
oder so etwas.
Ja,
ich würde nicht
die Technologien
selbst in
der Strategie
inkludieren.
Und das ist etwas,
über das ich
auch darüber
nachgedacht habe,
dass es
eine Strategie
für dieses Jahr
gibt.
Und du sagst,
oh,
wir brauchen eine
internen
Entwicklungsplattform,
weil das
diese und diese
Probleme
lösen wird.
Und für
irgendeinen Grund
startest du
im Januar,
du startest
im Juni.
Ich würde nicht
meinen Namen
in einer Technologie
in diesem
Kutting Edge
im Januar
sein,
wie es
im Juni
sein wird.
Ich denke,
die Technologien
sollten da sein.
Du solltest entscheiden,
welcher Cloud Provider,
wie du sie benutzt
wirst.
Für diesen
muss die Technologie
da sein.
Für Strategien
von
wir werden
die Entwicklungserfahrung
verbessern
bis zum Ende
des Jahres,
was wir
tun wollen,
und Teil davon
ist,
dass wir
besser mit
den Ideen
integrieren wollen.
Ich würde nicht sagen,
dass wir
von Tag 0
mit Visual Studio
oder VS Code
integrieren wollen.
Ich würde sagen,
wir wollen besser
mit Ideen
integrieren.
Wir werden eine Phase
der Forschung
machen,
welche die
am meisten
genutzt
und gut
erhoben sind.
Und dann
entscheiden wir.
Das Wichtigste
für diese Strategie ist,
besser mit
der Idee
zu integrieren,
nicht mit welcher Idee.
Für große
Migrationen,
wenn du
von MySQL
nach Postgres
migrieren willst,
musst du
dich
in der
Art
der
Idee
konzentrieren.
Und dann
kannst du
die
Idee
mit
den
Ideen
integrieren.
Und wenn
du
die
Idee
mit
den
Ideen
integrieren,
dann
kannst
du
das
mit
den
Wettbewerben
machen.
Wenn du
eine
Entscheidung
hast, die
einen
Loch unter
der
Wetterlinie
machen wird,
brauchst du
eine gute
Entscheidung.
Wenn sie
über der
Wetterlinie
ist,
ist es
okay,
du
wachst.
Für
kleinere
Entscheidungen
weniger
Einwohnung
von
den
Wettbewerben.
Und
ich war
involviert
als Teil
von
der
Leadership
Level.
Ich habe nur
einige
Bedingungen
gesetzt.
Zum Beispiel
wollte ich
Cloud Native
sein,
damit wir
die Kosten
später
optimieren können.
Wir wollen
es in
Kubernetes
runten,
weil wir
die Kosten
optimieren.
Es ist
eine
gute
Entscheidung,
die
wir
haben.
Wir
wollen
die
Kosten
optimieren.
Wir
wollen
die
Kosten
optimieren.
Wir
wollen
die
Kosten
optimieren.
Wir
wollen
die
Kosten
optimieren.
Wir
wollen
die Kosten
und die
Kosten
en
nicht
übertragen
.
Das
sollte
bei
Kubernetes
auch
sehr
tätig
sein .
Aber
an
VP oder
CTO
Niveau,
es wird
constituiert, es wird
wie du in der Zukunft funktionierst, in einer großen Art und Weise.
Aber einige Tools, wie Backstage und all das,
aber das Problem ist, dass es nicht so viele Optionen gibt für Backstage,
das ist der einzige, der die Entscheidung für dich gemacht hat.
Aber wenn es zwei oder drei Contestants gäbe,
denke ich, dass das mehr eine Konversation sein könnte.
Okay, aber das bedeutet in der Regel,
dass auch wenn du nur Entscheidungen über die Wasserline delegierst,
das noch viel Verantwortung auf individuelle Teams aufbaut, nicht wahr?
Was geht es darum, Teams zu ermöglichen,
diese Verantwortung effektiv und sicher zu nehmen?
Es gibt zwei Wege, um über diese Liste zu denken.
Eine oder mehrere Dimensionen.
Eine ist, dass man sicherstellt, dass es ein sicheres Umfeld gibt,
wo Leute Fehler machen können und wir von ihnen lernen.
Also wirst du nicht öffentlich für Fehler verurteilt,
aber du arbeitest mit.
Du arbeitest mit ihnen, um sicherzustellen,
dass wir lernen, dass jeder von der Entscheidung lernt.
Und es hängt auch vom Niveau der Kompetenz ab.
Wenn du delegierst, delegierst du nicht das Gleiche für alle Individuen.
Einige Individuen haben viel bessere, andere Fähigkeiten als andere,
sodass du einige Taschen delegieren kannst.
Du musst also beachten, dass die Teams die Fähigkeiten,
die Wissen und die Erfahrung haben, um diese Entscheidungen zu machen.
Du kannst sie trainieren, hiren oder trainieren,
coachen sie, um auf dem Niveau zu kommen, um diese Entscheidung zu machen.
Dann geht es so, als wäre es auf der Wasserlinie.
Aber du musst auch sicher sein, dass es als eine Gelegenheit ist, zu lernen.
Nicht, wenn du das nicht richtig machst, dann werde ich dich verletzen.
Ja, niemand wird Entscheidungen machen oder endet alle mit Kaibm.
Das ist der alte, berühmte Quote.
Niemand wird verletzt, wenn man Kaibm wählt.
Also musst du ein bisschen experimentieren.
Und sicher sein, dass es okay ist, wir haben einen Fehler gemacht, wir lernen davon.
Also klingt es so, als ob das auch Teil deiner Strategie sein sollte,
diese Art von Kultur zu bauen, die Teams in Bezug auf, ich weiß nicht,
Fähigkeiten und Organisationen zu ermöglichen.
Würde das nicht richtig sein?
Ja, ich denke, das ist richtig.
Du planst die Strategie, du nimmst all diese Komponenten.
Und ich denke, dass, jetzt, dass du es erwähnt hast, es in den Umfeld kommt,
was du die Strategie für machst, denn wenn du die Strategie machst,
machst du es, um ein paar Probleme zu lösen, aber du hast die Grenzen des Umfeldes,
für das du eine Strategie bauen kannst.
Und diese Teil des Umfeldes ermöglicht Teams,
Entscheidungen zu machen, wenn das die Strategie ist, die sie folgen wollen.
Vielleicht willst du diese Strategie nicht folgen wollen.
Du bist wie ein Top-Down-Approach, der in einigen Umständen funktioniert,
oder unter einigen Umständen.
Aber ja, Teil der Strategie zu machen, ist wie, wir werden diese Entscheidung handhaben,
weil wir sie ermöglichen wollen, und sie werden mehr engagiert, wenn wir das machen.
Also ist es definitiv Teil der Strategie.
Gibt es gemeinsame beste Praktiken für Infrastrukturstrategien,
um sich davon zu erinnern, oder in irgendeiner Art und Weise
kann man einige Ideen verkaufen und nicht von Anfang an anfangen,
oder von einer Art und Weise auszutauschen, basierend auf dem, was funktioniert und was nicht funktioniert?
Denn Strategie ist meistens eine langfristige Sache, die man sich umsetzen kann.
Also ist es wahrscheinlich gut, einen Startpunkt zu haben.
Ja, ich denke, es gibt definitiv beste Praktiken,
wo es jetzt ein bisschen eine schlechte Reputation gibt,
für irgendeinen Grund, aber sie sind beste Praktiken, die ich denke,
du kannst anfangen, sie zu bekommen, du kannst dir helfen, deine Strategie zu orientieren.
Lass uns sagen,
ich bin nicht mehr mit AWS kennengelernt, das ist die einzige Cloud, die ich professionell benutze,
aber du hast AWS beste Praktiken und CIS, das Center for Internet Security Benchmarks.
Also du könntest sagen,
wir, ich meine, ich glaube nicht, dass jemand sagen würde,
wir wollen unsere Plattform weniger sicher machen.
Aber lass uns sagen, dass du sagst, okay, Teil der Strategie dieses Jahres ist,
dass wir versuchen müssen, dass die Plattform sicher ist.
Und das ist irgendwie
unheimlich.
Es ist nicht der Sinn, es zu sagen, aber was ist die Strategie?
Also du könntest sagen, wir werden CIS Benchmarks für AWS benutzen
und wir werden AWS beste Praktiken und die White Papers benutzen, die sie haben.
Und das wird dir die Strategie helfen.
Ich denke, das Problem ist, dass es keine beste Praxis gibt, um eine Strategie zu bauen.
Es gibt viel Lärm und es gibt einige gute Praktiken.
Du hast einige gute Bücher.
Aber es gibt keine Strategie,
zumindest die ich kenne, wie eine Template-Strategie für Infrastruktur.
Es gibt einige Dinge, die fast immer wahr sind.
Du willst eine bessere Entwicklungserfahrung.
Du willst schnellere Entwicklungszyklen.
Du willst mehr abhängige Software.
Aber es ist immer eine Balance.
Manchmal willst du viel mehr abhängige Software,
viel mehr Software als Entwicklungserfahrung oder viel mehr abhängige Software als Entwicklungserfahrung oder
die Geschwindigkeit der Feature-Belieferung.
Also ich denke, das ist business-spezifisch.
Und du kannst sehen, was andere Unternehmen
an einer ähnlichen Phase und einer ähnlichen Größe für die Beleuchtung gemacht haben.
Aber leider glaube ich nicht, dass es eine Template für Strategie gibt,
weil es so kontextabhängig ist und so businessabhängig ist,
dass es sehr schwer ist, über die Strategie zu denken.
Ich mag William Larsen, er hat einen guten Post,
den ich vielleicht teilen und in die Show Notes schicken kann.
Oh ja, wir legen das in die Show Notes.
Danke.
Und das Buch Good Strategy, Bad Strategy.
Das ist eine Art Bibel für Strategie von Richard Rummelth.
Das ist ein guter Leser, aber es wird dir zeigen, wie man eine Strategie bauen kann.
Nicht,
eine spezifische Strategie für Infrastruktur oder Technologie oder
was auch immer. Es geht darum, wie du weißt, ob das eine gute Strategie ist oder nicht.
Ja, ich wollte nur fragen, ob es einige gute Startpunkte gibt.
Danke, dass du diese beiden Ideen oder Ressourcen vorgibst.
Und natürlich musst du entscheiden,
basierend auf der Situation deiner Organisation,
ob du oder ob du wirklich neue Entwickler benötigst.
Dann ist es vielleicht wertvoll, um die Bedürfnisse der Entwickler zu priorisieren.
Vielleicht sogar vor dem Kunden.
Wenn die Kundenbasis breit und wach ist und das Wort von Maus zu Maus ausbreitet,
dann ist es wahrscheinlich nicht so wichtig, wenn du einen sehr guten Wert verwendest.
Es ist nicht so wichtig, um die Bedürfnisse des Kunden zu erhöhen oder sich auf die Bedürfnisse des Kunden zu konzentrieren.
Also aus diesem Grunde, ja, ich stimme dazu, was die Situation angeht.
Ja.
Aber seit wir über Menschen gesprochen haben,
würde eine solche Plattformstrategie auch in Bezug auf das Verorganisieren von Teilen oder sogar all deine Organisationen reichen?
Ja, absolut.
Ich denke, das muss sein.
Nun, total.
In meiner aktuellen Rolle, zum Beispiel,
würde es total Teil der Strategie sein und es ist Teil der Strategie.
Also wenn wir über die Strategie denken, zum Beispiel wollen wir uns viel darauf konzentrieren,
weil wir wissen, dass wir eine gute Erfahrung dieses Jahres haben.
Also eine der Dinge, die wir machen wollen, um diese gute Erfahrung zu erreichen,
ist es, eine Erfahrungsteilnehmer-Team zu erstellen und die zwei Teams, die ich leite, in drei Teams zu dividieren.
Eine wäre die Erfahrungsteilnehmer-Team, weil ich denke, es macht extrem klar,
was die Bedeutung dieses Teams ist, was die Ziele sind und was der Fokus ist.
Wenn du es in demselben Team hast, ist es wirklich einfach,
dich von allem zu zerstören und Prioritäten zu verändern.
Aber wenn du sagst, nein, Erfahrungsteilnehmer-Team,
dein einziges Ziel ist es, die Erfahrungsteilnehmer-Team besser zu machen,
dann ist die Frage, welche Erfahrungsteilnehmer-Team ich besser mache.
Nicht, ob ich EKS verbessern muss oder die Plattform stabilisieren muss.
Also ich denke, für größere Organisationen muss es am meisten Teil der Strategie sein.
Andererseits, weil ich viel Erfahrung in kleineren Organisationen habe,
macht es nicht so viel, weil du nicht so viel umzusetzen hast.
Also zum Beispiel die erste DevOps-Strategie, die ich gemacht habe,
war ich und jemand anderes.
Also, wie viel du mit zwei Leuten machen kannst.
Und ja, es ist wiederum kontextabhängig.
Aber in größeren Organisationen sollte es ein Teil sein, um sicherzustellen,
dass du die Ressourcen und die Kapazität, wo sie sein sollten, um deine Ziele zu erreichen.
In kleineren Organisationen, vielleicht kannst du ein bisschen damit spielen,
aber es wird sehr hart sein.
Ja, aber du sprichst immer noch über dieses Thema von Verletzungen.
Vielleicht kannst du ein bisschen mehr darüber sprechen.
Ja, ich denke, das ist eines der größten Probleme, die ich für die Erfüllung deiner Strategie sehe.
Das sind Verletzungen in zwei Gründen.
Und das ist etwas, worüber ich mich als Leiter sehr viel denke.
Und ich sage meinen Teams sogar, wenn ich dich verletze, sag mir, umdrehen zu lassen.
Und dann komme ich zurück, bis ich meine aktuellen Aufgaben beende.
Und ich denke, es gibt zwei Art von Verletzungen.
Die wichtigen, die du überlegen solltest.
Zum Beispiel, wir arbeiten auf dem langfristigen Projekt oder migrieren in Argo Workflows.
Aber die Stabilität der Deployment Pipelines,
und das ist einer der Gründe, weshalb wir aus Jenkins und dem aktuellen Setup migrieren wollen.
Es ist nicht großartig.
Also manchmal ist es so, dass es aufhört zu arbeiten und jeden Deployment Setup beeinflusst.
Und damit habe ich mit dem CTO gesagt, ich weiß, wir haben dieses langfristige Projekt.
Wir haben einen Meilenstein in einem Monat,
aber ich möchte zwei, drei Wochen in der Plattform stabilisieren, weil das jetzt sehr schmerzhaft ist.
Also lasst uns die Abläufe ein bisschen weiter entfernen, damit wir das lösen können.
Also ich denke, das müssen wir immer noch umsetzen.
Und wenn du die Strategie verändern musst, weil eine wirklich wichtige Sache kommt, musst du das machen.
Aber es gibt
die kleinen Dinge, die nicht wichtig sind, wie Mikrodistraktionen, die viel hinzufügen.
Zum Beispiel frage ich einen der Teamleute, hey, kannst du mir diesen Dashboard geben?
Kannst du mir diese Metrik geben?
Kannst du mir diese, ich möchte das von P99 zu P75 in diesem Dashboard ändern?
Also es gibt Dinge, die wir als Managern sehr schnell fragen,
zu unseren Vorschlägen oder den Leuten, mit denen wir leiten.
Und wir denken nicht, oh, morgen werde ich fragen,
warum hast du dieses Ticket nicht beendet?
Du hast gesagt, du wirst es morgen beendet.
Und dann habe ich die Hälfte des Tages von dieser Person verpasst,
um stupide Dinge zu fragen, die nicht wirklich für die Ziele zählen.
Also ich denke, es ist nicht einfach.
Ich mache es immer noch, und ich denke darüber immer mehr.
Also du musst dir als Leiter bewusst sein,
von all den Fragen, die du fragst und all die Interaktionen, die du hast mit den Leuten,
die zu dir antworten, entweder direkt oder indirekt.
Du musst die Sicherheit bieten und die Teams ermöglichen, zu sagen,
hey, kann ich das morgen machen, weil ich das beenden möchte?
Und es ist sehr hart.
Ich habe versucht, ich habe dem Team gesagt,
sag mir ernsthaft, lass dich alleine lassen.
Und sie tun es nicht so oft.
Also muss ich sie wieder erinnern, dass sie mir sagen können, das ist nicht wichtig.
Ich will diese andere Sache beenden.
Aber ja, es sind die Verletzungen.
Die Mikrodestruktionen sind ein
großes Problem, obwohl du denkst, es sind nur fünf Minuten,
aber es sind fünf Minuten, wie 20 Mal pro Woche.
Und die Mikrodestruktionen, die ich denke, du als Leiter musst wehren.
Ist es wichtig genug, uns von der Strategie zu bestrafen oder nicht?
Und manchmal wird die Antwort ja sein.
Ja, es ist interessant, dass wir immer wieder zurückkommen
auch zu diesem Thema von erhöhter Effizienz und darüber, wie wir etwas Zeit abschneiden können.
Und etwas, das ich ziemlich
bemerkenswert finde, ist dieses berühmte Webcomic XKCD.
Vielleicht hast du es gehört.
Der Kerl, der es schreibt, ist manchmal sehr interessant.
Nicht wirklich Comics.
Und eines der Dinge, das er macht, ist wie ein Tisch, in dem er sagt,
wie viel Zeit du investieren kannst für eine gewisse Zeitverschuldung,
abhängig davon, wie oft du eine Aktivität machst.
Und wenn, ich weiß nicht, wenn du fünf Sekunden 20 Mal am Tag sagen kannst, dann bedeutet das, dass du dir
ich kann es nicht erinnern, eine Woche von Optimierungseffort investieren
und du kommst voran in einem Jahr oder fünf Jahren Zeit.
Es ist ziemlich interessant.
Ja, das ist sehr interessant.
Ich war, ich war in den alten Händen für unsere Ingenieurarbeit.
Aber ich habe meine Seite in den alten Händen
für unsere gesamten Ingenieurorganisationen letzte Woche.
Und eine Sache, die ich in ein paar Artikel gelesen habe,
diese Mikrofeedback-Lupen und sie waren wie fünf, zehn Sekunden, 20 Sekunden.
Und
eine Teil meiner Präsentation war, eine war, dass wir diese Debex-Champions
in den Teams kreieren wollen und die andere war, dass ich den Ingenieuren sagte,
wenn du etwas hast, das zehn, 20 Sekunden, eine Minute dauert und du es oft machst,
lass uns wissen, weil wir dir helfen werden.
Ich möchte diese Feedback-Lupen abschneiden oder sie entfernen.
Und einer der Ingenieure kam zu mir und sagte, ich hätte das nie gedacht,
wenn du das nicht gesagt hättest. Ich denke, die Leute sind so verwendet.
Und ich sagte, ja, wenn du sieben, zehn Sekunden hast,
wenn du es genug Mal pro Tag machst, ist es wert.
Und es ist nicht nur einer, es sind 100 Ingenieure, 130, die wir haben.
Also stell dir vor, ob es wert ist oder nicht.
Ich denke, die Leute denken einfach nicht nur über diese kleinen Mikrofeedback-Lupen.
Und das ist etwas, das ich erwähnt habe.
Und die Leute waren überrascht und wir werden damit beginnen, daran zu arbeiten.
Ich denke, die Leute denken einfach nur über diese kleinen Mikrofeedback-Lupen.