Kubernetes is an enterprise architecture
Five years ago, in the Pivotal Cloud Foundry days, we had a lot bravado. We almost challenged people, dared them to do something radically different. The mindset of doing daily releases, collapsing together multiple roles into product teams (business analyst-cum-product manager, developer, designer - this second a totally foreign concept to most enterprises) and then automating so much infrastructure that ops people were sort of not needed - it was a lot to process if you were a VP of Infrastructure in 2015, or even a CIO.
We would call this an “opinionated” platform. Brian Gracely was the first I remember to thoroughly describe what was going on here. His distinction between structured (“opinionated”) and unstructured platforms was great. We should have hired that guy! :)
Whatever it was called, opinionated/structured meant that meant that we’d made choices about how you architect your application, packaged it, instrumented it, and run it. To get all the benefits - for it to even work - you’d have to follow these opinions. Early on, these types apps would be described as something like “12 factor apps” using microserves. I think we call them “cloud native” apps now.
I kept making the analogy to J2EE, seemingly like that weird old uncle who can’t stop talking about the Korean war or Regan. J2EE had (has?) a lot of opinions about how apps are architecture, networked together, packaged, instrumented, deployed, and run in production.
In both all these cases, what we have is an application architecture, also an operations one. To be that old guy: just like we had with J2EE. This is incredibly valuable.
Having a standard that vendors and enterprises follow is valuable because:
- Vendors stop creating competing architectures and standards. Instead, they focus on competing how well the platforms run and how the outcomes they achieve. In the case of J2EE and kubernetes: the developer experience and how well the platforms runs in production directly drives the business goals you’re trying to get with the apps. See the Air France KLM modernization story below for an example.
- Vendors and the open source community focus all their efforts around one thing rather than energies duplicating each others efforts with incompatible platforms and programming models.
- Similarly, on the user/buy side, you don’t have to spend time coming up with this all on your own. You don’t have to build custom platforms and programming models that will (1.) cost millions to get to the first version (and likely a year), (2.) likely not work too well (cf. all the DIY kubernetes projects you rarely hear about, and the “boy, we really need to move of that Tomcat app we created ten years ago” stories), (3.) have to compete with rival DIY platforms in your company (“politics”), and, (4.) even if you “win,” you’ll quickly stop funding and developing the platform (there’s a very poor business case for funding your platform versus funding business-facing apps - it requires fear and regulations, as in security).
- Because the application architecture is already specified and an industry standard, developers and operations people know it. Eventually, “skills gaps” are not so huge. It’s not like J2EE developers grew on trees, but you could find them. They could just read some O’Reilly books and pretty much be set. It was even easer with the rails and LAMP stack set.
Overall, all parts of the tech industry should want to standardize on the app architecture and platform approach.
When it comes to kubernetes, we all get so wrapped up in it being, I don’t know, like cool skate board tricks (it’s hard to do, you break your bones a lot, but boy it’s cool when they work) that we forget this architecture standard benefit. I don’t think we even discuss it that much: to find the architecture you have to (as I’m doing here) take out a paint brush and carefully dust away the dirt like you’re extracting a fossil.
Now, there’s a lot left to be done. For example, in one of the podcasts below, Nate and I discussed when you’d put something as simple as circuit breaker in service mesh (like Istio), a container sidecar or containerized pod-buddy, or in-app code. When you don’t standardize that early on, we end up putting that kind of code in every component and layer which is wasteful and confusing. You know: inelegant.
Anyhow. Realizing that there’s an architecture there is, you know, needed. And then after that, we all need to start nailing it down now.
I’m not really a fan of the “making the technology boring” framing (I mean, it’s fine, just not the contrarydiction I’d choose), but it’s making a point that I agree with: once you get kubernetes all up and running, all you have is a blinking cursor and a whole new series of problems to solve. You have to design a whole distributed application architecture and operations methodology, and the tools that go with it. And then you need to get budget, time. and staffing to decide on that, test it out and refine it, implement it, and (like, a year later), you’re still at a blinking cursor. Then you can write your applications. Or, you could skip all that, and just go with the architecture that’s already there.
But, hey, that’s just my opinion.
From The Name of the Wind:
Manager, Heal Thyself! - The panel I put together and moderated for this year’s SpringOne. It turned out really well. Here’s the abstract: When you’re trying to improve how your organization does software, how do you change what managers and executives do? We hear a lot about how developers and operators change, the composition of product teams, and always about Kubernetes. But there’s very little conversation about transforming management. This panel of managers will discuss what managers’ and executives’ roles new and old look like, managing managers, and how individual managers can manage their careers when their role changes.
- Software Defined Talk: There is no passion in peanut butter and jelly sandwiches - Coté and Brandon discuss Chef being acquired, the Private Equity Operating Model and Gartner’s Cloud Infrastructure and Platform Services (CIPS) Magic Quadrant. Plus, Coté offers advice on peanut better and jelly sandwiches.
- Tanzu Talk: Responsible Microservices, with Nate Schutta: Sometimes you feel like a microservice, sometimes you feel like a monolith. In this episode, Coté talks with Nate Schutta about his new book Responsible Microservices: when to use them, when to use a service mesh, the (false?) hope of polyglot programming, monolithic shaming, and giant zucchinis.
App modernization at an airline
This is one of the talks I was looking forward to at SpringOne. It’s about the airline I fly, KLM. I’m always hungry for stories of regular companies modernizing regular apps. It didn’t disappoint.
Here’s my notes and highlights on it as well.
I value talks like these tremendously because they’re “real world,” not the alternate reality of tech companies.
I don’t find stories and lessons learned about and from Spotify and Netflix too helpful or convincing or helpful for, you know, regular companies. As one review of Reed Hoffman’s advice put it:
Hastings’ real superpower as a manager — one that he never really admits to in the book — is that, thanks to the gravity-defying Netflix share price, he isn’t cash constrained. In fact, the more cash he burns, the more valuable his company becomes.
If you’re in that situation as an enterprise, you play by a different set of rules, constraints, but also opportunities. Airlines couldn’t be further than “isn’t cash constrained.” So, stories about how they manage to do better at software are incredibly helpful for that ongoing study. Plus, they’re a Pivotal/VMware Tanzu customer!
Lessons learned from modernizing the 12 year old payments system at Air France KLM. There’s a lot about managing stakeholders, planning what to modernize from a monolith, and getting staff to work in a new way.
I spend too much time trying to get my 20+ years of notes, common place books, writing, and shit organized. I’ll be an old man soon and will want sift through all that shit to figure out what the fuck happened to that bright, optimistic version of myself that thought the future was great. That little fucker was so happy and indomitable!
At the moment, I’m trying DevonThink. It’s kind of overwhelming, but I think it will work well.
DevonThink’s syncing approach is stupidly complex. In the sync section in their manual, they start by saying “it’s really quite simple” or the like. Anytime a manual says that, it means it’s actually complex and confusing. There’s a lot of steps and you have to bend your mind around local database files, storing database files on Dropbox, and, I don’t know - it’s confusing. Every other app that syncs across mobile and desktop has one step: login to Dropbox (or iCloud). Then you’re done.
Also, I really, really want an app like Evernote, DevonThink, Ulysses, Drafts, DayOne - whatever - that just uses pure files instead of it’s own database. I want that system to be an overlay for a bunch of sprawling directories. I don’t think such a system exists (“it’s more optimal for searches to be in a database,” blah blah, I’m sure). I really liked Roam Research, but it was all online and with no mobile app. Microsoft OneNote is close (it’s actually very similar to DevonThink with it’s weird file-based databases thing).
Anyhow, we’ll see. DevonThink also has a huge community that answers lots of questions and creates all sorts of extensions
I wish Evernote had just continued to evolve instead of becoming such as weird cul-de-sac of mid-2000s thinking.
With kids, all bets are off
Up to that point in my life, there had been surprisingly few instances in which I could not defeat a problem with hard work”
– Cribsheet: A Data-Driven Guide to Better, More Relaxed Parenting, from Birth to Preschool, Emily Oster
What the swag-set are up to
- They don’t waste time feeling sorry for themselves.
- They don’t give away their power.
- They don’t shy away from change.
- They don’t focus on things they can’t control.
- They don’t worry about pleasing everyone.
- They don’t fear taking calculated risks.
- They don’t dwell on the past.
- They don’t make the same mistakes over and over.
- They don’t resent other people’s success.
- They don’t give up after the first failure.
- They don’t fear alone time.
- They don’t feel the world owes them anything.
- They don’t expect immediate results.
From 13 Things Mentally Strong People Don’t Do: Take Back Your Power, Embrace Change, Face Your Fears, and Train Your Brain for Happiness and Success
Cool story, bro, but it left off item 14: the chemicals in their brand aren’t all fucked up.
Still, in so much as I’m always looking for the script and character-mask I can put on when I need to deal with life, it’s a good list of what that movie looks like.
Relative to your interests
Follow my blog if you want to see these during the week. I often add additional commentary to the links there that doesn’t show up here (e.g., developer landgrabbing).
- Oracle Introduces the MySQL Database Service on Its Cloud Infrastructure - I don’t hear about MySQL much anymore.
- Move from the Bay Area, get paid less - ‘But employees who worked at VMware’s Palo Alto, California, headquarters and go to Denver, for example, must accept an 18% salary reduction, people familiar with the matter said. Leaving Silicon Valley for Los Angeles or San Diego means relinquishing 8% of their annual pay, said the people, who asked not to be identified discussing internal policies.’
- Little boxes - ‘McLuckie has explained that with containerised applications running on an Infrastructure-as-a-Service (IaaS) model, code could be written in a hermetically-sealed unit, from which it could be deployed, whole, into disparate environments — a test cloud and a production cloud, for instance.’
- Modernization is all about little, strategic loops where you decide what to work on next - ‘At VMware Pivotal Labs, we take a six-step iterative approach to mainframe modernization that provides the business with both incremental gains and ROI.’
- Sharp edges - ‘“We’re seeing Kubernetes emerging not just as an infrastructure service abstraction, but as a dominant control plane for driving workloads, whether those workloads are running in Linux application containers or pretty much anywhere. And that’s an absolute delight.... The downside is that “it’s a fancy system and it has some really sharp edges.” This brings us back to the goal of simplifying the developer experience. “Creating a comfortable environment that uses the power of the system, that doesn’t force them to deal with all these sharp tools that can cut them all the time, is very important,” said McLuckie.’“
- Deep work if no value - ‘I’ll get obsessed with figuring out how to do something that will in no way offer profit or real benefit to me or anyone else.’
- Portability isn’t a thing with kubernetes - ‘Kubernetes facilitates portability because it helps standardize our software development life cycle and, most importantly, our operating model. However, it also adds management overhead to our organization, it forces us to engage with commercial vendors and to completely rearchitect our applications. Implementing portability with Kubernetes also requires avoiding any dependency that ties the application to the infrastructure provider, such as the use of cloud provider’s native services. Often, these services provide the capabilities that drove us to the cloud in the first place. In conclusion, the portability tax is high. Make sure to pay it only for applications that truly need it and that are likely to switch infrastructure provider at some point. For all the others, don’t choose Kubernetes on the basis of a universal portability principle, just because it “sounds right”. On the contrary, adopt Kubernetes for agility, scalability and for modernizing your application architectures.’
- Getting ready for change sure pays off when things change - ‘Strong digital foundations are already helping leading companies adapt to the crisis quickly. One global retailer that invested for years in true omni-channel sales and delivery had already offered curbside pickup at 100 of its stores. When forced to close its physical stores owing to COVID-19, in just 48 hours it was able to expand its curbside service to 1,400 stores while maintaining a majority of its revenue. Meanwhile, many of its competitors struggled to shore up their online channels.’
- Large enterprises are the only developer market that pays for anything - ‘So maximising adoption for even the best product or first mover, in enterprise software, means producing open source software that caters to developer preferences. It means creating a supported, highly manageable product that can be sold to the FTSE1000/Fortune 500+. ‘
- Gartner on Google Cloud - ‘How about Google? Gartner said it is also strong for “every use case,” apart from edge, which is a rather strong caveat. It has won developer “mind share” via open source Kubernetes and TensorFlow, and according to Gartner, “closed a number of critical capability gaps between GCP and Azure.” The analysts were not happy with GCP’s availability record, however. “Google’s much-vaunted network capabilities have been the source of a number of GCP outages during the last year, with devastating impact on customers,” they wrote. The fact that GCP is “a small fraction of overall Google revenue” is also a concern, presumably on the basis that if parent company Alphabet were to decide to change track, the cloud product set might no longer keep pace with its competition.’
- Paid plan for IFTTT to do multi-step actions - ‘As a user, I stopped playing with IFTTT as often as I used to, simply because the format was limited for all that I wanted to do. ‘
- Giving developed the tools to do security checks - ‘Synk and other cloud security vendors have focuses on container image registries as a weak link in the cloud-native application development workflow. Aqua Security, the Boston-based infrastructure security specialist, released a similar scanner earlier this year targeting Docker container images and Harbor, an open source container image registry project backed by the Cloud Native Computing Foundation.’
- Describing tasks - ‘Consider “consider”. Tasks that start with the word “consider” give you the ability to track optional tasks. My database is full of tasks like, “Consider cleaning studio,” and, “Consider setting client check-in calls”. ‘
- Lasers - ‘Supplying equipment to automakers, on the other hand, is a notoriously cutthroat, low-margin business. If Luminar can’t sign up other automakers, it could find itself yoked to a demanding but not especially lucrative customer.
- What is a Tanzu servicemesh? - ‘A service mesh decouples services from having to know about the network and helps developers to focus on business logic. A typical service mesh can provide: Service discovery; Weighted routing (for A/B deployments); Mutual TLS based authentication (including certificate rotation); Advanced telemetry for in-depth observability; Fault injection and retries; Circuit breakers’