It works on my computer!

We’ve all been there.  We’ve installed, configured, or developed something that works perfectly on “my computer” or “my dev environment”, but under release testing it stops working.

There is a period of troubleshooting that diagnoses an application / plugin version mismatch, or configuration constraint.

Then there is the deployment window for updating the servers to accommodate the missing app prerequisites, which in turn requires its own round of testing.  At which point we find that the prerequisite application/configuration isn’t compatible with an existing application, or the necessary changes will compromise server integrity.

I’ve been in or seen this situation countless times.

What if we could have a server system that isolates each (part of an) application so it doesn’t matter which version of Java I use!

Introducing Containers

Containers are virtualised application services that run just enough code to make your app work and are completely abstracted from the underlying server infrastructure (If you are familiar with App-V, or Citrix ThinApps then the idea is the same).

Key advantages for containers are:

• Only the resources needed by the application are spun up meaning that a container has an extremely small resource footprint, a very small attack surface, and in turn is extremely agile
• They contain the information necessary for self-replication(bursting) during peak usage (replication is handled via a container orchestration service such as Docker Swarm or Kubernetes)
• Complete separation from the underlying server architecture and other services/containers – you could describe it as application virtualisation rather than server virtualisation

Build Once, Run Anywhere

Containers offer two big advantages for anyone developing applications for your organisation whether they be in-house or via a partner:

• They allow a little freedom for devs to use the building platform they like such as their own laptop.  Once ready for release they provide the app requirements such as; Apache 2.4.33 and PHP v7.2.  Your managed service provider can spin up the containers using those specs, while your devs upload your code. There are still most of the usual risks under testing, apart from the risk of affecting existing apps, or server configuration, which is reduced to zero!
• Alternatively, why not develop directly in containers and “Bring Your own Container“?  Containers with the relevant services that devs need for their apps can be spun up from a repository or registry.  This approach means that the risks of release management are reduced because the apps are written for operation in a uniform manner regardless of where the container is located

What Do Microsoft Offer in this Space

Microsoft have offered container services in GA for a little over a year in the form of Azure Container Service (ACS) where you can run Docker, or Mesosphere orchestration engines to manage containers.

Service Fabric has been running for longer and is also a platform for deploying Microsoft native microservices/containers.  It’s the platform that a lot of Microsoft services run on such as Skype for Business, CRM online, Power BI, Intune and Cortana.

The latest offering is Azure Kubernetes Service(AKS) which is a managed Kubernetes orchestration platform – currently in preview.

Microsoft‘s aim in this area is to provide a world leading managed containers platform that meets all requirements.  They are making gains in this area by simplifying the management overhead, improving security, and enhancement by virtue of other Azure services such as OMS, Security Centre, IoT, etc.

For more of an overview on containers and how Azure services are evolving to meet demand there is a very eloquently written post describing containers here.

Stay tuned for an in-depth view of each service, how they compare, what their compelling features are, and what the future holds.