I maintain that the real reason for AWS’s success is that it is a developer enablement platform. Many AWS services exist to enable developers to write code specific to the business problem they are trying to solve. Do you need a message queue? There is a service for that. Do you need an event broker? Guess what? There is a service for that too. By using these pre-built services, which are consumed through an API, it is easy to spend time writing the code specific to your business. Without the services, you spend more time writing code that implements technologies rather than business processes.
On the other hand, I have always felt that docker containers are a great way to distribute the software you write, but I never thought of containers as managed services. Then came the day that I needed to build an application to deploy at far-edge locations where there are no application services and few resources to spare. The fundamental edge platform for new applications is docker, and applications get delivered as containers. How do I provide a database for the edge location? I could create and maintain my own container image precisely to my specifications or use a pre-built container image, MySQL, pulled from the Docker Hub. The image needed a few environment variables to configure MySQL with a database name and credentials. The same with messaging; I used Mosquitto in a container. However, I rebuilt that container to embed one configuration file since I couldn’t immediately see how to pass the configuration as environment variables. Both containers were pulled directly from Docker Hub public repositories, and neither was heavily modified for my application. Passing environment variables to the containers is much like providing properties when using an AWS service.
I did also build my own containers for my code. Written in Python, I used standard libraries to access MySQL and Mosquitto and spent most of my time writing business-specific code. I currently use docker-compose to orchestrate the ephemeral containers that make up my application and have all data persistence in an AWS-managed service (DynamoDB) rather than on-site. For my use case (a demonstration application), using pre-built container images was a viable alternative to managed services and certainly more productive than building every image from the ground up.
For many use cases, much more is required than a pre-built image from public repositories. For example, how about security attestation for the software and configuration inside the image? Or data persistence and protection, which are essential. Is the image setup to simplify using container volumes to hold data? Mature container development and operations teams will have solutions for these issues, but they are not inherent in the pre-built image, unlike managed services that usually address these issues.
The other issue was the difference in the options for passing configuration. The Mosquitto image wanted a volume to hold a configuration file, while the MySQL image was happy with environment variables. The MYSQL image has excellent documentation about persisting a database or importing a dump to create a new database at the start. It would be great to find more container images that are this flexible and well-documented.
Building an edge application with some pre-built container images allowed me to focus far more effort on building my application’s functionality. It isn’t the same as using cloud services to build applications, but I like it more than building applications to install in VMs. I do wonder whether there are good edge application platforms that deliver some managed services to enable application developers.
© 2023, Alastair. All rights reserved.
RSS - Posts