Red Hat Summit: Clouds today, serverless tomorrow
Have you ever thought to yourself, “Today’s world would be so much richer if we had 29 kinds of hummus?” Neither has Stephanos Bacon, Senior Director of Portfolio Strategy for Red Hat Application Platforms. His entertaining presentation moved from the options available to humans hungry for hummus to a discussion of the bewildering array of choices available to developers and architects. Although too many choices can be a bad thing1, it’s important to understand what choices are relevant today and that the relevance of those choices is always shifting.
There are several things that don’t change, however. Some of the concerns that have been with us since before the dawn of time2 include:
- Making developers as productive as possible
- Balancing productivity with governance and compliance
- Delivering software predictably and in a timely manner
- Making software as robust as possible
- Prioritizing usability and accessibility
But beyond these goals, there are three factors that are always in flux:
Everything you need to grow your career.
With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development.SIGN UP
- Changes in technology
- Market imperatives
- Cultural and process changes
As an example, Stephanos pointed out some of the changes developers have gone through over the last 15+ years. Dynamic linking was all the rage at one point; static linking was bad. (Eventually that turned into actual rage as DLL hell and similar problems complicated our lives. But I digress.) Now that we’re in the container era, we’ve actually taken static linking to another level. Instead of simply binding the object files for various libraries into our executable as our great-grandparents did, a container has the code for our app, the libraries it uses, probably a JRE or some other runtime, and even the OS tied together. The changes brought about by the three dynamic factors make static linking the obvious choice. For now.
Scaling is another area that has changed over the years. In the early days of web apps, our goal was architectures that scaled up. We wanted our apps and our data centers to handle surges in traffic, so we built them accordingly. With the rise of cloud architectures, scaling out has become the norm. A side effect of this change is that startup times are now crucial.
Continuing the theme, in the early days of Java, the mantra of “Write once, run anywhere” made it possible to ignore the underlying OS to an extent that had never been possible before. With the portability of containers, and the fact that containers have their own baked-in OS, developers have the option to write more OS-specific code.
Stephanos wrapped up the talk by pointing out the necessity of hybrid clouds, a major focus for Red Hat. It’s not sustainable for developers to modify the way they develop, test, package, deploy, or monitor their apps depending on the cloud provider.
All in all, an insightful look at the developer landscape, where we’re going, and why the path forward looks the way it does. Change is constant, and understanding the factors that influence it is crucial.
1 Seriously. Hummus should be hummus, just like it has been for thousands of years.
2 Yes, these things mattered prior to 1970.
To learn more, visit our Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets (e.g. containers), books (e.g. microservices), and product downloads that can help you with your microservices and/or container application development.