Contraints make better products and architectures

I love constraints. I can make decisions and products much better if I take away choices. DevLab is a product that embraces limitations. This platform is not for everyone because it is a commodity platform for commodity API projects. Nothing on the market matches it. I am not recommending building from scratch. If you can, you should build on top of a platform that enables you to craft an experience. Offering the default platform as is, is a temptation for you.

Product Name Style Target Offering Abstraction Level On-premises Support?
Civo Cloud Managed Infrastructure Self-Service None No
Heroku Bring your app and config Self-Service Medium No
Dev.Lab API-First Design Experience White-glove High Yes
Digital Ocean Kubernetes Managed Infrastructure Self-Service None No
Digital Ocean App Install Blueprint or container Self-Service High No
AWS Light Sail Install Blueprint or container Self-Service High No
Azure App Service Bring your own container/app Self-Service Medium No
Azure Kubernetes Service Managed Infrastructure Self-Service None No
Humanitec Bring your own container/app Self-Service None Yes
AWS EKS Managed Infrastructure Self-Service None Yes
Platform.sh Learn our config syntax Self-Service Medium No
Okteto Cloud Bring your own namespace Self-Service None Yes
Giant Swarm Managed Infrastructure Self-Service None Yes
releaseapp Bring your own container/app Self-Service None No
Dark ML language abstracts infra and apps Self-Service High No
ToroCloud Bellini/Martini Web app, integration as a platform Self-Service High No

The wrong kind of utopia

First, let me point out what utopia is not. It is easy to read books about architecture and walk away with an absurd idea of what software architecture means to a business. Imagine all the data is up to date, standardized, cataloged with extra metadata compiled. Every system is event-driven and can scale up and down as the need arises. Every service is unique. All its parts are reusable. Data transfers between systems via agreed-upon data models. When not using a common data model, systems scrub and reformat the data for better reuse. Sounds like paradise, right? Nothing in this story points to the value delivered to customers. These features are part of long-term sustainable value delivery in the long run but not an end goal in themselves.

The right kind of utopia

The utopia I am trying to create with my product focuses on appropriate business trade-offs. I want to embrace the constraints of a business. A business that focuses on a coordination operating model will make better decisions. I want to offer the golden path to teams solving business problems. Imagine that you are a brand new software developer straight out of a boot camp. You want to be successful and work on business problems. You learned React, JavaScript, and Ruby in your boot camp. Now you’re working for a .NET shop. Uh oh! It’s ok because the job-to-be-done is to work on a brand new speculative business project to improve a customer experience. The team you are on is all new in some fashion and has come together to solve this business problem. Your team works through a design sprint to understand what the business experts desire. Thinking through what systems need to connect to make it happen.

The first result of that initial design sprint is the experience you and your team think will solve the problem. Now it’s time to start implementing the code. You access the self-service portal and pick your desired contract for your project. Database? Secrets? You enter them in an instant. Does this use a common business data model? Better pull one of those in and save us some time. We are implementing our code and test driving it at the same time. The rapid inner loop is firing on all cylinders. We iterate, expose, and explore what connecting the pieces means. We discover the different user journeys. We find some missing information as part of the API. Increment the version add the missing pieces. Sync the changes back into our codebase and put in place the missing functionality. It feels powerful. The systems that power all this fade away. Solving the business problem and obtaining feedback from our market is paramount. Coordinating with other teams is unnecessary. Bottlenecks of other departments turning around tickets are a figment of the imagination.

Coordinating with other teams is unnecessary. Bottlenecks of other departments turning around tickets are a figment of the imagination.

Conclusion

Running a business is about making tough choices. You cannot make everyone happy. Do not aim to do that. Are you using a platform to focus on your highest leverage as a business? Or are you trying to do a thousand things a tiny bit better? How’s that going for you? Customers want to pay for the best product experience at a value they can afford.

  • Make your life simpler and embrace the constraints you have.
  • Identify your leverage points and invest in them.
  • Acknowledge your trade-offs and make them part of your decision-making process.

What trade-offs are you making? Are you making the right ones? What delivers the most leverage for your teams?