We titled the #CloudMinds KubeCon huddle, “Containers + Programming Languages: Together at Last.” In hindsight, we probably should have added a caveat: “Together at Last …sort of.”
We learned at last night’s event, which brought together 15 experts from across the tech landscape, that there’s work to be done when it comes to making containers and programming languages more interoperable and complementary. IBMers John Duimovich and Jason McGee hosted the event, which sought to ask the fundamental question: How can programming languages and containers evolve together to better serve the developer?
As always with our huddle recap, I’ve broken out some of the key insights we heard in bold and some of the lingering questions beneath them. It’s our hope that our #CloudMinds participants and
There exists a huge opportunity for infrastructure providers to get closer to what developers need, meet them where they are, and simplify the concept count for developers as they adopt new technologies in the container ecosystem.
How should the container ecosystem should evolve to better focus on the developer’s product?
Where does the biggest opportunity lie when it comes to creating a cohesive developer story?
While there’s plenty of focus on simplifying operations and orchestration systems, there’s a larger piece that sits on top of orchestration — “a platform play” — that deserves attention. Considering the lifecycle of a service from a developer perspective — from creation to deployment to operations — there are multiple steps involved, but there’s not really a cohesive story pulling all of it together.
What is the opportunity to pull these pieces together for a more cohesive developer experience and an end-to-end developer story?
How do we inspire the broader industry to focus on the developer story?
A service becomes successful when developers don’t realize it’s there anymore. With services that are on the leading edge — like containers, microservices, etc. — we find the opposite is true and they require a high degree of engineering focus.
How does Kubernetes get to that place where it’s needed and necessary, but has “disappeared” in a sense?
Abstraction can be a double-edged sword. While development teams may want and benefit from abstraction at various layers, too much abstraction can be frustrating because it can create “too many guardrails.”
Are we providing developers with too much flexibility in certain areas? Not enough flexibility in other areas? How can we identify and address these?
As an industry, we’re transitioning from an infrastructure-focused view of development to an application-focused view. While we’ve made a lot of strides in solving the back half of the problem, much work remains in solving the front half of it.
In an application-centric world, how do people in the SRE role start to narrow down where problems exist?
Are we also transitioning to a model where development teams own the entire end-to-end application lifecycle?
It’s a requirement to have global transaction information available at all times when you’re at the application layer. Having vision into end points of failure that don’t require human intelligence and interpretation has become necessary to creating these complex systems.
How can we start to provide an interface for application-level transaction information for the entire system?
Is this something that programming languages can offer as a built-in concept or as a clear idiom?
How can we begin to share these concepts across open source libraries?
Making the assumption that nearly 100% of applications are delivered in containers, and since applications are written in programming languages, this naturally will impact the way languages and frameworks are constructed and delivered.
How do we ensure that programming languages evolve in an industry standard way that’s multi-language?
We’ll continue the discussion in the coming weeks and months, and even seek to answer some of these lingering questions. To those who attended: please feel free to share your reactions, insights and takeaways from our conversation.