TLDR: Make things easy to undo
When working through a piece of code, designing and interface, architecting an application or doing whatever lies before you, there are are a LOT of decisions to be made. What language should I use? What frameworks should I use? Cloud offerings? Backing data store? Monitoring tools? Looping constructs? And any of dozens of other things that cross our keyboards on a daily basis.
Some of these decisions tend to be obvious for the particular problems we are working on. Using text files to store and search through gigabytes of data seems like an obviously poor choice, for example. But other decisions can get a bit more nuanced. If you go down the container rabbit hole, for example, do you want it hosted on a stand alone VM running docker? Use kubernetes? Some hosted service like an Azure app service? Do containers really even make sense in the first place, even though everybody seems to use them all the time for all the things?
When faced with these types of decisions I try very hard to make a choice that is easy to change or back out of later. As a current example I can briefly walk through how we ended up in Azure App Services and are mostly happy with it.
We were starting a new project. Here is a list of the various thoughts and concerns that had crossed the teams mind
- We had decided it would be service based.
- We want to encourage engineers to use the best tools for the job, although we are organically coming to rely on a set of tools, some hosted, some home grown, that make deciding on certain languages and such a more obvious choice, but we didn’t know that at the beginning.
- We probably thought we wanted to end up in containers, but weren’t 100% sure about that. I love them but some of the people on the team still had a learning curve with them. And we had a prototype to get done to show stakeholders ASAP.
- Data storage? Who knew?
- Our team is very small. How much time, effort and manpower are we going to dedicate to dealing with machine spinup and maintenance?
One of the things we had to decide initially was how to host the new application. Thinking about all these things and viewing the offerings we had available now and in the future, we ended up going with Azure App Services. In the short term it solved these problems for us.
- It could build our existing code bases and run them. We could defer the user of containers
- Using containers, since we were likely going that route longer term, was supported
- Very little infrastructure to support and maintain for our team
- Ready integration with a whole bunch of other services in Azure
- It didn’t care about the granularity of our services. Host a monolith in there? Roll out a dozen services? Fine. Roll out more? Probably less fine
And it gives us some flexibility going forward
- We are now on containers. The migration from shipping code to be compiled by the app service to shipping a container was not a big lift and could be done independently of feature work
- With a little bit of work on the networking side and some other services we can effectively set up an architecture that is robust, scalable and secure
- Integration with several different build tools as we continue to build out our CI/CD pipeline and improve our practices around testing and delivery
And of course, some things to be wary of, because there are always tradeoffs. Always.
- Beware easy integration into all things. We need to be vigilant about what services we want to adopt for a quick win and what services we need to be sure we leave as agnostic as possible so we can make changes as we see fit
- Costs. All of these hosted services make things very easy. The tradeoff for ease of use is often dollars.
- Language and platform lock in. Things run very well if you are using .NET, Python and NodeJS. The further you wander off these tools, the more interesting things can become. Since we have containers this is mostly mitigated, but not 100%
We will likely end up in kubernetes eventually, but it did not make sense for the first iteration. Now that we are on containers and people are up to speed on using them and we have the foundation for a build pipeline in place, this migration should be pretty easy, if we even get there. For me hosting this on any sort of stand alone machine was a non-starter. I didn’t want to deal with it and, strangely, nobody else did either. At this point we’ll see how far we can go with App Services.