On Platform Engineering and DevOps

Some off-the-cuff thoughts after attending a platform webinar yesterday.

I've not heard a clear presentation on 'the platform engineering kool-aid' yet, so it was interesting to hear that yes, we continue to look for silver bullets.  However, there were some insights to be taken from it.

Platform engineering has some concepts/principles that are useful to understand:

  • Platform requires a certain level of organizational maturity (you are already doing pipelines and IaC)
  • Both organizational and engineering vision-clarity (our value prop is stable, our market share is growing, we understand our JTBD better than ever)
  • You need scale - while paradigms can be applied from day1, the dividends of platform are most obvious with, let's say, 50 engineers and up.
  • API access to our 'platform' enables automation - i.e. design for programmatic access
However, DevOps was presented as 'baby's first platform' - you do pipelines, great - now grow up and do platform engineering.  (my lasting impression, 24h later, anyways)

The juxtaposition of 'DevOps vs. Platform' or 'DevOps -> Platform' is silly, and is derived from the commoditization of philosophies.  This commoditization panders to our inherent selfishness and laziness - silver bullets only, dear sir!

'DevOps Tooling' for example, is an atrocity against the whole point.  Platform tooling, also, helps one escape from the point with the sunk-cost-fallacy confidence that a five- or six-figure purchase order gives you.

So, rather consider things from the 'why' perspective:
  • DevOps reveals that you must view things systemically from a culture, a way of working, that is founded on informed continuous improvement of the right things.
  • Platform reveals - as does SaaS in general - that scale requires clarity of purpose, commitment, and automation.
So it's incoherent to state these things are in opposition to one another, or superseded by one another.  What could we say, then?
  • The DevOps paradigm creates conditions for wildly better outcomes and sustainable change
  • The platform paradigm creates clarity on how you solution your continuous improvement execution
Paradigms drive your day-to-day choices, so let's remember that understanding why you do a thing has more lasting value than actually doing the thing.

Comments

Post a Comment

Popular posts from this blog

Learning through failure - a keyboard creation journey

Image
tl;dr Built a custom keyboard cuz I have weirdo nerve pain issues.   Learned a lot cuz I failed a lot.   Maybe 'do it right the first time' is a bad frame of mind.   The keyboard ended up being kinda nifty.   It has lights, and a trackball, and QMK, and it helps my issues.   \o/ ( tl;dr is internet lingo that means, too long; didn't read ) Pain as a key ingredient An old proverb says, 'necessity is the mother of invention', and that is how this story begins. Over the last few years, age or stress or something has caught up with me and I developed the need to change my human-to-computer interface.  Mousing changed to trackballing.  The traditional keyboard was swapped out for an ergonomic, and then split keyboard.  Complicated multi-finger-and-hand key combinations were replaced by single keypress macros.  And yet more was still needed. It's often said that change only happens with pain - indeed, the organizations many...
Read more

Learning Opportunities - Watching/listening list

Over the last year I've spent a lot of time learning (thank you, long commute & lunch hours).  Many topics ranging from Chef to DevOps to architecture concepts to management concepts and everything in between.  Why have I done this? DevOps Demystified with Ben Rockwood: https://www.youtube.com/watch?v=h5E--QSBVBY DevOps at ancestry.com: https://www.youtube.com/watch?v=pF5ya0q53kk Those two presentations were key in sending me down this road.  First, and most important, was Mr. Rockwood's explanation as to the real 'why', and the point behind DevOps from an operational perspective.  Second, and no less important but for a different reason, the continuous delivery system at ancestry.com really made it real to me because they are a 'Windows shop'.  So much of what I'd been reading about Chef/config mgmt. relied on amazing tools (see the error there?) only available to the Linux world.  Suddenly here's this guy telling me that it's possible...
Read more

Fixing duplicate SPNs (service principal name)

This is a pretty handy thing to know: SPNs are used when a specific service/daemon uses Kerberos to authenticate against AD. They map a specific service, port, and object together with this convention: class/host:port/name If you use a computer object to auth (such as local service): MSSQLSVC/tor-sql-01.domain.local:1433 If you use a user object to auth (such as a service account, or admin account): MSSQLSVC/username:1433 Why do we care about duplicate SPNs? If you have two entries trying to auth using the same Kerberos ticket (I think that's right...), they will conflict, and cause errors and service failures. To check for duplicate SPNs: The command "setspn.exe -X C:\Windows\system32>setspn -X Processing entry 7 MSSQLSvc/server1.company.local:1433 is registered on these accounts: CN=SERVER1,OU=servers,OU=resources,DC=company,DC=local CN=SQL Admin,OU=service accounts,OU=resources,DC=company,DC=local found 1 groups of duplicate SPNs. (truncated/sanitized...
Read more