Arguably the hottest thing in software right now are microservices, containers, and Docker (a specific implementation of the containers model).
The concept of microservices, put simply, is to have very small services that are mostly independent of each other and can be easily and quickly changed, upgraded and supported. The seminal work, The 12-Factor App, goes into more detail and is a terrific read. But for now, let's just say microservices means very small web services talking to one another without a lot of entanglement. Think small, fast, few or no dependencies ... the very opposite of a monolithic system.
Containers are basically very small units of computing power that start very quickly. Where several Virtual Machines (VMs) can run inside of one physical server, now imagine several containers running inside of one VM.
Finally, there's Docker. Docker is a specific implementation of containers. One of the major advantages of Docker is that it is growing rapidly as a technology, with a strong and surging infrastructure. In other words, it's the hot technology.
Bringing them all together is where things get exciting.
Imagine, for example, publishing a web site from your IDE into a Docker container for testing purposes. Click a link, the solution builds and is published. The Docker container starts up within seconds -- like, say, five seconds -- and you have your web site. Ready for testing. In a Docker container.
Want to let another developer on your team recreate your work? They merely follow the same steps and they have their own Docker web-hosting container ... again, within seconds.
Think what that can do for rapidly scaling your application. Imagine, for example, giving every user their own container to do work, then removing the Docker container when they're finished.
Consider: You have, say, five Docker containers, each running the same small app -- er, excuse me, "microservice" -- running behind a load balancer. They're humming along, doing fine. Life is good.
A few days later, after some feedback from customers, you decide to add a feature, or supply more data, to the service. Your small team modifies this service -- written in, say, Ruby -- and does due diligence with regard to testing, code reviews, etc. It's ready to deploy.
At 5pm on a Friday.
(Okay ... I'm joking about that past part.)
Now you're ready for a "rolling update" .... where you add five new Docker containers behind the firewall (in a matter of seconds!), then wipe out the five older containers. Within seconds, you upgraded your service.
This speed becomes a Godsend when you discover a software defect that needs to be fixed NOW. As dangerous as it may be, the power to be able to change the source code and redeploy within a few minutes -- from opening your editor to running the updated code -- is a reality in this new world view.
Like any sharp-edged tool, microservices, containers and Docker cut both ways. But like any good chef, it's up to you to know when to use the tool, how to use the tool, and take care not to turn a beautiful creation into a disaster. Now that you've been introduced to this exciting technology, play around, experiment, and see how it may work for you.
In other words, accept the challenge. Again.
