Platform Strategies & Platform Engineering | Gregor Hohpe In The Engineering Room Ep. 24
ฝัง
- เผยแพร่เมื่อ 12 มิ.ย. 2024
- Gregor Hohpe. is a world-class expert on software architecture and the role of the architect, he is a technologist and expert on the topics of large-scale systems and the public Cloud as well as lots of other stuff. Gregor is currently part of the Serverless team working as an Enterprise Strategist for Amazon at AWS,
Previously he was Technical Director in the Office of the CTO at Google, and before that was Chief SW Architect at Allianz the German Insurance giant.
Gregor is an international speaker, author of Several great books, as well as writing on his always thought-provoking blog, “The Architect Elevator”. and he’s just published a new book called “Platform Strategy”
___________________________________________
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
___________________________________________
🖇 LINKS
🔗 "Architect Elevator Blog" architectelevator.com/blog/
🔗 "Architecture as Code" architectelevator.com/cloud/i...
00:00:00 Intro
00:01:24 Start
00:01:38 What is a Platform?
00:03:21 "Platforms are Abstractions that Work!"
00:05:20 Why we Only Find Good Platforms Every 20 or 30 Years?
00:06:11 Good Platforms Remove Work
00:08:07 Should we Leave Building "Platforms" to Others?
00:12:04 Where Platforms Go Wrong
00:14:04 Good Platforms Change the Vocabulary
00:15:14 Common Mistakes in Platform Engineering
00:21:45 You Need VERY Skilled Devs to Build Effective Platforms
00:22:33 Focus on the Problem Not the Tech.
00:23:19 Sinking vs Floating
00:26:34 Keeping Options Open through Architecture
00:27:50 Platforms - the Pinacle of Good Design
00:29:01 What Strategies Work?
00:32:43 Using Platforms to Join the Dots
00:35:27 Reducing Cognitive Load
00:40:10 New Programming Models for the Cloud
📚 BOOKS:
📖 "Cloud Strategy", Gregor Hohpe ➡️ leanpub.com/cloudstrategy
LINKS:
📖 "Enterprise Integration Patterns", ➡️ Gregor Hohpe amzn.to/47r2j56
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
#podcast #softwareengineer #platformengineering - วิทยาศาสตร์และเทคโนโลยี
![CAMPปลิ้น | EP.76[1/2] โจโฉเปิดป่าโหดรับโอ๊ต-ป๊อบ รอบนี้พี่เอาจริง!](http://i.ytimg.com/vi/pNg5O7Pf-a0/mqdefault.jpg)
OK, I will now admit it. Gregor is much smarter than me ;-). I love the way he seems to read my mind - e.g. about "floating vs. sinking platforms" and the necessary "Decision discipline". Very similar to some of my own experiences, ideas and struggles but articulated so much more clearly. Looking forward to reading the new book.
Thanks for this video. Our devs have generally told us (I work as a member of a Cloud Platform Team) that they like having us define defaults in templates for cloud services that provide a “golden path” on the platform so they don’t have to spend time via trial and error. We don’t generally block devs for anything unless it is a cyber security requirement, most “default” settings in the templates can be easily overridden if the dev needs to for their specific situation. Also, we have had to build abstractions for identity systems (service principal creation and management, etc…) as the devs on every team don’t want to have to spend time figuring this out on their own, etc….
Just sharing some of our journey’s experiences.
Great to have you both sharing your thoughts together 1+1 > 2! Can't wait to get you both back into our firm for more talks!
This is the stuff - I wish here was more of it.
Many thanks for what PG Wodehouse's Uncle Fred might call "a pleasant and instructive afternoon."
As stated near the end, the tech domains (such as distributed systems) are long overdue for proper programming models that compile to executable code.
I would even argue that it makes sense to develop a regular (as opposed to embedded) DSL for certain domains that would allow more idiomatic expression than something like TypeScript.
btw, my initial exposure to DDD was a 1/2 day class taught by Eric Evans in 2006. There was this guy in the row in front of me who was far quicker than the rest of us in absorbing the content.
I knew who he was cuz I had just purchased his book "Enterprise Integration Patterns."
This is a tremendous talk with so many tips and insights about this topic that needs to be clarified nowadays (to me at least). Thanks for this video.
Great discussion! Ive just bought the platform strategy book, cant wait to see what else I learn :D
Great vid! It sounds to me like people often use the word platform when they really mean tool. From someone who has spent a lot of time working on both. A platform is something you stand on that gives you wide access to functionality. A tool is something that customizes that access.
CDK - specifically the latest Typescript version - is a perfect example to me of well-managed complexity. Using SST alongside it is incredible; I can build complex IaC structures with just a few lines of code most of the time. However, if I need extra control, I can delve into the lower-level constructs, deciding how much complexity to take on to solve my problems. Also, for infrastructure elements that we find are commonly needed, like an audit trail, we create small custom constructs backed by unit tests. This simplifies the communication of our strategy with teams and requires very little documentation since they use the same ubiquitous API that everyone is used to with CDK. This is our platform, and it really feels like it reduces our cognitive load (*wink*) without confining us.
The thing I struggle with is knowing what things should be centralised and what things should not? Most centralisation I see seems to cause problems and slow the organisation down, but at the same time, if every team does its own thing then will this not end up slowing down the organisation also? A simpler question to ask is "how important is organisational consistency?"
"They are happy with the P in there" such gold but missed the chance to say "They are happy with the PP in there" 😂
Platform Engineering unfortunately is being implemented (in my region at least) as a team or department and so is now a new Silo and reintroduces all the issues caused by silo’s we so briefly shed before DEVOPS was corrupted by those with interests in returning to the bad old ways with all new names slapped on.
I’m now seeing articles on medium and LinkedIn offering the bad old solutions to the bad old problems of silos which we have now reintroduced with all new silos. Sigh.
Yep. Meet new buzzword "platform engineering", same as old buzzword "SOA", same as really old buzzword "CORBA". I don't get why the IT industry insists on building the same exact nonsense over and over again.
@@GackFinder in terms of the way Management, Consultants, Tool Vendors and Agents work together to cycle every revolution in software development back around to doing the same old bad things just with the new labels intact it’s because new things that fail are blamed on the one who signed off on trying it while old things that fail are expected and don’t move the needle on personal responsibility/exposure, consultants want to sell what management wants to hear, tool vendors want to continue to sell the same products they always have and agents want to supply managers with roles they want to hear about.
This is the third cycle I’ve been through in my 26 year career and I’m really struggling to find the fortitude to dive back in once again.
The IT industry will build so much utter nonsense under the umbrella of "platform engineering" that I as a consultant will probably be very rich by simply helping my clients to clean up the mess they will invariable make. "Platform engineering" is just yet another IT buzzword for something that isn't generally needed, and it will rarely, if ever, reach any kind of return on investment. In other words, "platform engineering" is simply waste. By the time you've provided your fully working "platform", all frameworks and tech stacks that it abstracts away will be old news, and your "platform" won't work with the new stuff. It's the utter folly and mythology of "reuse" all over again.
Agreed.
So what is your view on this talk then? Let's talk content.
@@AmorFatiYT Assuming you're referring to me and my view... I believe I've already given my view on the overall topic in no uncertain terms. Unless you've got a specific question or comment and can attach it to a specific video timestamp, I'm unfortunately unable to elaborate any further.
Platform engineering does not work in an organization that is always chasing the latest trends without understanding. However, in an organization that values stability It can work.
Hohpe is not a strategy
🤣Actually I think that Hohpe is a pretty good strategy in most cases.