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?