8 1/2 Things We Learned at SpringOne Platform: New Ideas and Key Affirmations for the Modern Enterprise.

September 27, 2018 Jared Ruckle

Pivotal’s goal is to help your enterprise become a learning organization so you can go fast forever. As SpringOne Platform winds down, it seems only fitting to reflect on what we’ve learned at the conference.

How best to sum up the flurry of product announcements, keynotes, customer stories, hallway conversations, and tech talks? Let’s place our takeaways into two camps: new ideas to take to your business, and key affirmations about the state of modern software development.

First, we examine what’s new. 

Pace is the new OSS packaging.

How do smart enterprises think about bringing open-source into their org?  A popular strategy is “try-it-while-I-wait-and-see.” When new tech hits GitHub, by all means, bang on it. But don’t rush to put your apps in production with it. And it’s usually a bad idea to implement these things as homebrew DIY initiatives.

Instead, give the hot new project a few quarters (or a year) to bake. Get involved in the community. Ask your vendors how they plan to build the tech into their offerings. If the vendor offers a compelling, credible answer, you should make them a “trusted partner.”

And when that hot new project becomes a mature, useful project? Make sure your trusted partner has a plan to help you keep pace with the velocity of said project.

This is a big change. Previously, a given version of a commercial open source product would be supported for a year (or longer). Now, the most important open source projects ship quarterly releases. Weekly patches, too.

The important question to ask your providers: How can you help me keep pace with the open source projects that matter?

Onsi Fakhouri explained Pivotal’s philosophy in the opening keynote:

Good open source tech tends to spread.

It’s tough to keep up with all the goings-on in open source. SpringOne Platform though illuminated a key point: good open source tech spreads. When one community comes up with a useful abstraction, other groups adopt it.

For example, Istio and Envoy solve common networking problems for microservices. In fact, both projects are foundational elements of a service mesh. So, Cloud Foundry is embedding this tech to the platform.

Buildpacks are a wonderful way to accelerate developer productivity. Why? They build the container for the developer, and assemble framework dependencies at runtime. Enterprises use this tech in production, at scale, all over the world. This success has piqued the curiosity of other communities. Now, the Cloud Foundry and Heroku communities have teamed up to bring buildpacks to the CNCF! The CNCF just accepted Cloud Native Buildpacks as a sandbox project.

Finally, the Open Service Broker API. This tech is already used by Cloud Foundry and Kubernetes. It’s how you add backing services to your apps. And options for public cloud services were on full display at SpringOne.

In his keynote, Bruno Borges mentioned all the services now available in the Azure Open Service Broker.

Amazon just launched their own Service Broker for PCF:

And our friends at Google authored an GCP Service Broker for PCF too:

It’s time to invest in event-driven architectures.

Like open-source tech, new patterns should be experimented with early and often. If you haven’t played around with event-driven architectures, now is a good time. The electrifying keynote from Neha Narkhede of Confluent made the case exquisitely. 

Let’s recap why. First up, what problem are we trying to solve? Better integration across enterprise data systems. Traditional approaches are a pain the rear. You end up with spaghetti architectures like this:

Well, Kafka can solve that:

Not only is your architecture cleaner with Kafka, you can respond to events in real-time. Better still, your response can take the nature of the event itself into account. So when a user performs a certain action, you can execute logic that takes that context into account. The result is a faster, smarter customer experience. 

Big banks are using it. So you have production references to study:

What about the operational side? Glad you asked! Kubernetes makes Kafka easier to operate...

...and now PKS makes Kubernetes easier to operate. This combination dramatically lowers your operational burden.

By now, though, you might be thinking - this seems like deja vu all over again. Are we kinda doing ESB, just in the cloud this time? Not if you are thinking about events properly. There’s enough guidance out there to help you get smart about where and when to use a streaming platform:

Enterprise architects need to get out of the prediction game.

As you ponder your move to event-driven architectures, do so responsibly. A few talks about enterprise architectures offer up pragmatic way to look at complex enterprise systems.

Some of the most egregious behavior in enterprise IT? When practitioners cycle through one piece of tech after another. It can happen to the best of us, software architects included. Matt Stine offered a crisp definition of architecture that’s now more true than ever:

Under this backdrop, it’s important to be thoughtful about the decisions you make. Nate Schutta reminds us that it’s hard to deliver business value when you’re in a constant state of flux. So instead of attempting to predict what might happen in the future, focus on the now of your business.

What else can architects do to be more effective and relevant in the cloud era? It may not be new, but there’s several essential practices you might want to start doing in this post:

On to the affirmations!

It's Still about Outcomes

Pop quiz! Which of these is your CEO most likely to say:

  1. Great job using containers.
  2. Great job using a service mesh.
  3. Great job picking an OS distribution.
  4. Great job release new code quickly and responding to customers.

It’s “4,” right? Of course it is. It bears repeating every now and again. Stay focus on better business outcomes, not shiny objects. These enterprise talks at SpringOne Platform were great reminders to this end. Speed thrills!

Use the Highest Abstraction You Can

Raise your hand if you’re sick of the arguments over platforms, container orchestrators, and functions. Keep your hand up if you’re tired of reading about the cloud wars. These discussions are tedious and tiresome.

The reality is that enterprise IT is complex. You’re going to have many abstractions in your business, just as you’re going to have many clouds. That’s why Dave Syer keynote was so refreshing.

The message in this tweet isn’t a hot take. But it is universally good guidance for all you IT leaders out there. Don’t focus on the proverbial “one ring to rule them all.” Realize you are going to have many different abstractions. Then, focus on using the right abstraction for the right use case. Usually, it’s wise to use the highest abstraction you can get away with.

Multiple Abstractions Mean Very Little Without Operational Consistency.

All these abstractions are wonderful, aren’t they? Sure! But not if they’re an operational nightmare. Not if you can’t rapidly apply security patches. Not if you can’t do easy upgrades. So the corollary to the multiple abstractions angle is that you need a common operational model. Urvashi Reddy says that’s where BOSH comes in:

And when you do have a common operational model, your Ops team is free to run their platform like a product, as evidenced by Wells Fargo and US Air Force:

Secure Tech Reduces the Need for Security Tech.

Forward-looking InfoSec teams have a few rallying cries. Go faster to be more secure! Make the secure thing the easy thing! Pivotal’s Justin Smith lead a panel with Express Scripts, Mastercard, Merrill Corp, and West Corp. that reinforced the idea of CALM:

  • Culture. No conversation about modern software development is complete without culture. So what does a modern InfoSec culture look like? For starters, you should have a team of generalists and specialists, with an emphasis on coding ability. And you should rotate people on the security team for a few months at a time. This is a fantastic way to change how your teams think about security. Change won’t happen overnight, but rotations will make it happen faster than you think!
  • Automation. If you do something more than once, you should automate it. Scanning should be automated. And you should build service brokers to automate how your teams interact with add-on services.
  • Lean controls. A company can spend millions on traditional security products that offer marginal benefits. Instead, orientate around your PCF platform! Right out-of-the-box you can inherit so many security and compliance controls. (Check out Security and Compliance in PCF and Pivotal Cloud Foundry: The Auditor’s Guide for details.)
  • Metrics. If you can measure it, you can manage it. You need to collect and track the right data. Focus on the common KPIs like rapid patching, perhaps better known as mean-time-to-repair. We’re also seeing banks track the age of their systems. Why? Older resources tend to be more fragile. Strive for younger VMs, clusters, containers, and credentials. Don’t let your systems get stale!

Or the TL;DR:

Lots of articles have been written about the power of AI to improve cybersecurity. But if you can’t even patch all your systems quickly, why on Earth would you be focused on stuff like that? Wells Fargo reminds us that good patching hygiene and repaving your platform are two accessible security practices that you can take advantage of immediately with a modern platform.

Developers still just want to write code.

We can close out our recap with this eternal truth from Mark Charny:

Spring, Cloud Foundry, and API-driven infrastructure helped developers just write code. Now, you can add Knative to that mix as we move up the stack to functions.

See You in Austin Next Year!

On your way home, check out the other highlights of the conference. Want a run-down of all things Spring from the show? Diogenes Rettori has you covered:

We’ve got recaps from Day 1, Day 2, and Day 3 as well.

About the Author

Jared Ruckle

Jared works in product marketing at VMware.

Follow on Twitter Follow on Linkedin More Content by Jared Ruckle
Previous
Moving Toward DevSecOps: A Case of a Framework Standardization Team
Moving Toward DevSecOps: A Case of a Framework Standardization Team

Learn from the work on the standardization of software frameworks in the R&D department of a large Japanese...

Next
Continuous Delivery to the Cloud Wreaks of Humanity (and That’s a Good Thing!)
Continuous Delivery to the Cloud Wreaks of Humanity (and That’s a Good Thing!)