News / Technology /

The Latest Pivotal Cloud Foundry Sets the Stage for .NET Microservices

10 Apr 2017 1:00am, by

Last week’s official release by Pivotal of the latest version 1.10 of its commercial Cloud Foundry software services platform touts some significant — and perhaps overdue — improvements, including support for sister company VMware’s NSX virtual networking layer. This alone may be a game-changer for some organizations looking to install Cloud Foundry assets across cloud platforms, and needing to stretch a single security and access control layer across all of them.

But perhaps the most compelling innovation with this round involves support for a library you may not have heard of: Steeltoe. It is an open source effort, stewarded by Pivotal, to construct a Netflix-inspired microservices model for full-fledged .NET Framework applications — not just .NET Core, not Xamarin, but the full enchilada.

“I’ve been a .NET developer for the last 15 years and I haven’t seen platforms that run Windows at scale,” admitted Richard Seroter, Pivotal’s senior director for products, speaking with The New Stack.

“You can do configuration management, potentially. I can use Chef, I can use Puppet. But in terms of having infrastructure powered by Windows that you treat as a service… now we’re moving up to another level. I think it’s something that’s been long overdue.”

The Popular Table

Today, although Windows Server still maintains a presence as the management platform for Windows clients and the staging platform for client/server monoliths, the newest cloud-native services are being hosted on Linux. This creates a skills gap — one that, left unattended for years, is becoming a chasm. It’s not so much about Windows’ native architecture relying on centralization while microservices depend on distribution, although that’s clearly true. It’s that those legitimate languages, including C#, F#, Managed Jscript, and dare I say it, Visual Basic (VB.NET), have faced undue punishment for having been nurtured in an ecosystem separate from the one that made software-defined infrastructure possible.

“At Pivotal, we talk a lot about re-platforming, and deciding what to move,” said Seroter, without really needing to fill in the details about moving from what, to what.

“Frankly, I think our mindset is, just containerizing your old stuff is typically not worth the effort,” he continued. “There’s a whole crop of things that are probably okay where they are. They’re not business-critical, or maybe they are but they have a very low change rate, and you don’t have a problem with feature velocity. Some things that you do want to have in distributed systems probably deserve some light refactoring, so they can take advantage of horizontal scale, or new data stores. But there’s a good change if these are systems of record that don’t change much, they’re probably still going to be relevant to another microservice that wants to use their data. So while that thing doesn’t change much, somebody else needs it to do stuff. I think as you have more systems that can’t be siloed, they’re going to have to modernize for the sake of their ecosystems, if not just for themselves.”

Put another way, Seroter sees a measurable, if not always definite, need for some applications from the client/server realm to be re-platformed in a new architecture, just for them to co-exist with cloud services and the rest of the world. Such a move does require, at least to some extent, a skillful developer who understands the way the client/server platform worked or used to work.

What Stays and What Goes

We’ve talked before in The New Stack about Spring Cloud, which is Pivotal’s framework for rapid patterning and prototyping of distributed systems and microservices. It includes ready-made microservices that handle the functions that every distributed application will need — for example, service discovery, using the Netflix Eureka model; and a configuration store for maintaining state.

“I need to have configurations stored off-machine,” explained Seroter. “I don’t want any web.config files in my .NET app; I don’t want it in a local config. And I need a service registry. All my services are scaling, the IPs are fluid, and I can’t be hard-coding references to services in my app. That’s a runtime lookup.”

As you may know, Spring is built around Java.  Steeltoe effectively and deliberately shifts that relationship, from Java to .NET.

From a systems perspective, here’s what’s happening: Pivotal Cloud Foundry 1.10 is enabling the staging of distributed workloads on Windows hosts. For containerization, Pivotal uses Garden Windows, which is a set of open source Go libraries for producing OCI-format containers. PCF’s container scheduler is Diego for Windows, and its deployment mechanism uses the BOSH command-line tool — again, rewritten for Windows — for installing Windows cells (PCF’s staging platforms) and pushing .NET applications to those cells.

“A number of these patterns around configuration, service discovery, circuit breakers, OAuth — all these capabilities were part of Spring Cloud.  That’s downloaded millions of times per month.  Steeltoe came about, as we had a growing .NET practice saying, how come .NET devs can’t get on this fun? There’s nothing in this ecosystem that’s helping .NET devs build microservices. So Steeltoe is a set of components that let you plug into that ecosystem. It extends .NET Core and traditional .NET Framework, and lets you hook into that configuration subsystem to use a remote config server.”


This is not a trivial switch or even your typical mindset shift. For a veteran Windows developer, it’s a brain transplant. Windows applications built in Visual Studio have a notion of scope, as do all programs. But even as .NET architecture was taking over from its Windows predecessor, the Component Object Model (COM), for the sake of downward compatibility, the Common Language Runtime provided for global scope — static variables whose values and references transcended all subdivisions in an app. And for exchanging data between applications, there was still COM, which relied upon the persistence of a single global Registry (with a capital “R”). The thing that makes every Windows installation run more slowly over time… that’s the Registry.

Up until very recently, the whole idea of .NET development was to run an application within a Windows environment that behaved like a client, where everything is comfortable and co-existence isn’t an issue, like some pre-globalist, utopian vision. As a result, anyone learning a language like C# was also treated to a deep dive on the various Windows Foundations (the libraries that superseded the Win32 API). To learn a .NET language was, simultaneously and inseparably, to program for Windows.

For a .NET developer to use a Windows CLR language to build microservices for Cloud Foundry is to abandon some chunk of what she learned. But not all of it, and that’s the attraction. Embracing Netflix-style architecture no longer means chucking two decades of skill and starting over from “Hello, World!”

“Now a .NET dev can do service discovery,” said Pivotal’s Seroter, “and be part of this live registry — not this static, out-of-date, stale integration management database, but a live look that relies on heartbeats and health checks. And we have additional connectors in Steeltoe, so I can talk to popular, open source things like Redis, MySQL, Postgres, RabbitMQ, OAuth. These .NET devs are playing in the ecosystem that everyone else is, without so much friction.”

While Cloud Foundry developers have been tinkering with the Steeltoe frameworks now for some months, with version 1.10, Pivotal now provides commercial support. For PCF and Steeltoe, the experimentation phase has now ended.

Now that everything’s reassembled, it’s fair to say what emerges from the noise and dust doesn’t really look very much like Windows. Moreover, it’s the cloud-native model reiterated using languages made for Windows. No doubt, veteran .NET devs may spend the first several months in this realm feeling like immigrants in a foreign land. Whether they feel welcome or pushed to one side, like the other end of the cafeteria, will depend on whether all this openness you read so much about is as open as folks say it is.

Cloud Foundry is a sponsor of The New Stack.

Feature image: Fra Burmeister og Wain’s Iron Foundry, painted by Peder Severin Krøyer in 1885, in the public domain.

A digest of the week’s most important stories & analyses.

View / Add Comments