DevEx
Developer Experience (DX) is the equivalent to User Experience (UX) when the user of the software or system is a developer. DX describes the experience developers have when they use your product, be it client libraries, SDKs, frameworks, open source code, tools, API, technology or service. DX shares some ideas and philosophies from UX design (or HCI), but builds on these with an eye towards modern technology and standards.
The Best Practices for a Great Developer Experience (DX), in Hackernoon. Retrieved 2/24/2018. https://hackernoon.com/the-best-practices-for-a-great-developer-experience-dx-9036834382b0
Position on the Adoption Curve
Presentations about DevEx
Kubernetes: Crossing the Chasm
10k Deploys a Day - the Skyscanner Journey So Far
Improving Life in Smaller, Heterogeneous Projects
Taking Back “Software Engineering”
Develop Your Development Experience
Interviews
Kubernetes: Crossing the Chasm
What's your main focus at Container Solutions?
The majority of the time it's with customers, which in itself can vary quite a bit in terms of day to day activity. We focus on cloud migration which is a pretty wide topic. It could mean an initial assessment: where the company is in terms of Cloud Native maturity and where they're trying to go, as well as recommendations of what tooling to use or how to organize teams. Then we move to actual implementation. We work clients to set up a cloud platform or orchestration tool like Kubernetes, create a build pipeline, and even splitting out monolith applications into microservices, and putting them in containers. It usually includes some training along the way as well. We do a bit of everything.
Your talk is about when things don't quite fit into the normal path for Kubernetes. What does that mean?
Initially, a lot of the companies who came and asked about moving to Kubernetes were part of this ideal adoption path. Small companies, with mostly stateless applications, possibly already containerized, in small services. It's pretty straightforward, take these pieces, put them in containers, throw them on Kubernetes, leverage some cloud services, ideally such as databases. This was the happy path for Kubernetes. In the past year we've noticed something else. At first I just thought it was a series of interesting projects which happened to have an extra challenge, something which didn't fit the norm. It tended to be more enterprise organizations where they had different requirements, maybe running on premise, or needing to split across multiple datacenters or regions. One interesting project in particular: It was a modern SaaS-based startup, but they needed to run most of their applications in China. There were all these challenges that can be solved, but it's not obvious and finding resources to do it can be difficult.