After sleeping off the tiredness of a 48-hour hackathon on Cognitive Spaces and Workplace Transformation the Cisco Webex Innovation team held in Dallas this week I had a chance to look over our product again. Looking through the code (and shaking my head and wondering how some of these lines even resulted in a functional prototype) I noticed one very interesting aspect of the project. Let me show you the project directory and let's see if you can figure it out yourself:
servers laptops and interacted with two additional Webex devices as well as a Meraki access point and additional cloud services.
Looking back at the development experience it becomes apparent that all the good and bad aspects of developing software with microservices emerged in a project that couldn't be further away from a planned development process or, god forbid, software architecture.
The fact that, in just 48 hours, we could spin up a functional prototype without every getting into each other way nicely demonstrates how scalable, in terms of using programming resources, software development becomes once you adapt to the microservice mindset. The ease of distributing tasks became apparent when our front-end developer Ben build our gorgeous dashboard(no seriously, look at the screenshot below) without even knowing what the entire scope of the project was. All he needed were the visual designs and the description of the API endpoint that fed him the data later. In all fairness, at the time he started to develop the front-end that API endpoint was barely more than a freshly started Django app on my laptop and an idea in my head. All I knew was the type and representation of the data and that was all he needed to know as well.
The ugly aspects of microservices became apparent when my laptop (accidentally) connected to our company WiFi instead of the hackathon network subsequently bringing down the entire application with it. All services on my laptop suddenly were not reachable not only rendering the rest of the applications unusable but also stalling our entire development since no one could debug their services relying on data from mine anymore. And yes, in the real world, please please don't develop and debug against your production services but let's be honest we all have that one friend of a friend that does that anyway.
However, deploying additional features became a blast since every functionality was only a "Hey-I-really-need-this-thing" callout to the desk and a quick web request away.
Last but not least there is the aspect of reusability. While there is a good chunk of code in this project that (and rightly so) will never be touched again there are also some components that would be great to reuse and publish. Of course, a major refactoring of the code base is needed since the python code I produce high on three red bulls at 2 am is even worse than my 10 am code. While a monolithic approach would require me to first untangle all the stuff I want to refactor I can now just take the microservices I want and work from there. Even better I can run all of the other services as they are and test if my refactoring works or if I am breaking something.
In summary, microservices have their pros and cons but if you want to see them in action there is no better way then joining a hackathon and code away all night in a team of highly motivated people. Well, thinking about it, you should sign up for a hackathon regardless of your existing affinity to microservices. Also, feel free to rant to me about microservices on twitter. I am @squ4rks.
I will do a full write-up of the event including a description of our solution (and hopefully some Github links) soon and link to it here.