I believe that the Internet of Things (IoT) is a popular topic, in part, because its science-fiction becoming science-fact.  IoT promises all of the conveniences of “The Jetsons” without having to push buttons, while threatening to produce the surveillance states of “1984” or “Minority Report”.  Unfortunately, it most likely will give rise to the annoying doorways from Douglas Adam’s “Hitchhiker’s Guide to the Galaxy”, that have micro-transactional charges per use and in-app purchases that “allow” the door to open after 5pm.  For our

Oh DevOps, DevOps.

You hear time and again how it’s the future of application development and deployment. You’re told you need to implement it and engrain its best practices across your organization.

But making a shift from the old way of doing things, however error-prone, slow, or disruptive it may be in comparison to the agility and utility that DevOps promises, is no easy task.

When looking to build a microservice, you may have come across two pieces of advice; start with a monolith, and don’t start with a monolith.  For a good number of us developers in the trenches, the point looks irrelevant because we already have a monolith, so one to-do completed and moving on.  Not so fast!  The discussion goes beyond the greenfield experience of where to start.  Instead, within the “don’t start with a monolith” advice

With the growing necessity for companies to digitally transform, a lot of emphasis has been given to the microservices architecture, with its improved scalability and distributed design.  While these facets may apply to some, adopting microservices is equally about the universal DevOps goals of improving lead times and reducing the batch size of releases, ultimately leading to more flexible and frequent production deployments of higher quality software.