After sleeping off the tiredness from 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:
Got it? No? Still wondering what is in the "top secret" folder? Alright then let me help you: In the short span of 48 hours, our team of six developers built a total of 14 microservices. There is not one component in that folder that does not interact with another part of the application over REST calls. To give you an example, we have a React-based front-end component pulling data from a python+django based data backend that consumes a data feed from an analytics component written in Javascript and running on a Cisco Webex room device. For the demo, our application was deployed among three 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 ever getting in each other's 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 built 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 were suddenly not reachable, not only rendering the rest of the applications unusable but also stalling our entire development process 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 who 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. It's a beautiful show of how a microservice with a well-defined API interface lets you scale development teams.
Last but not least, there is also 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 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 than 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 on Twitter.
Category: Blog