Yesterday I got to spend the day at EMC here in Seattle for a Pivotal Cloud Foundry Workshop. I wasn’t really sure what to expect, and I wasn’t really sure I had any business being there to be honest. I don’t write apps, I don’t even manage servers. But, I’m curious, and Pivotal (DevOps/Continuous Delivery in general) represents change to how applications are written and maintained. This feels awfully relevant to me as I muck about at whiteboards with customers trying to figure out what to do with these puffy white clouds floating about the industry. The whole idea of cloud is of course tightly intertwined with orchestration and automation, and at the end of the day, all of that is for naught if you don’t have scalable applications. This brings us to the point of this post: Monoliths and Microservices.
Why do Monoliths and Microservices matter to a silly network guy like myself? At first I didn’t really think they did. Turns out however, that ALL of what these guys were talking about is so directly applicable to networking it’s not even funny. It seems to me app dev and networking are facing the exact same problems, and are trying to solve the problems in very similar fashions on totally separate parallel tracks. How do we successfully deliver a high quality product that can quickly and easily be upgraded, maintained, etc. (skewing things a bit to keep it applicable to networking)
At the end of the day when I build a network for a customer it’s not just about how good the network is up front on day 1. Thats EASY! What about at the end of year 5, when that pair of ‘core’ switches need to go in the recycle bin? The easiest parallel I can draw is VSS — I love VSS, don’t get me wrong. Its powerful, stable (now, wasn’t so fun back in the day though), single point of management, multi-chassis Etherchannel is great, etc. etc.. At the end of the day though, this is a Monolith — it’s a complex system (as Matt Stine said in the workshop, a simple = a single ‘thing’ essentially, complex = any number of simple things together — paraphrasing here!). There is nothing hard happening in a normal VSS pair; it’s just routing, switching, and maybe some service type things like netflow or whatever, but nonetheless its a complex system because it represents a lot of stuff all tied together. Old software stacks are just like this – relying on non standard functions to interact with other modules, being dependent on a DB of a particular flavor in a particular location etc.
So whats the alternative to these Monolithic platforms/applications? Microservices of course, didn’t you read the title? Microservices to the software guys seems to mean write an application for as small of a scope as possible — i.e. if you have 50 individual tasks that need to happen for some user experience, you would need 50 applications communicating across some standardized way to interact (REST?). So in networking land, we can take that and apply a similar logic (perhaps not to the same extent) – distribute the ‘load’, keep things as simple as possible. Taking the core example, I would (personal preference) not deploy VSS — instead I would deploy routed links everywhere, and keep as many services pushed out to the edge as possible (we know ISPs scale, we know MPLS VPNs scale — distributed systems tend to be pretty snazzy). This takes our ‘complex’ core, and makes it as ‘simple’ as we can. Keeping the analogy going, the routed links are the standardized way to interact wit the rest of the network. In five years, when its time to upgrade, just insert a new device, tune the cost down on the old, and traffic magically flips over to the new.
All in all I’m reminded that the industry is a funny place. It’s all cyclical, and things are happening at different paces in different disciplines. I find it funny that ‘networking is the last to innovate’ and that we are always waiting on the network — and I think thats 100% true in a lot of respects, but the network has to play to the lowest common denominator. In many cases that’s applications. Monolithic applications that can’t scale and can’t be distributed because they were never written to live in a world where clouds rule. The guys at Pivotal want to change how apps are built so that we can move forward, and I’m very much looking forward to that. In the meantime, we in the network realm can try to build the most ‘simple’ networks possible, build Microservices, not Monoliths, ensuring that we too can be nimble (trying hard to not to say ‘agile’ here!) when it comes to network designs, upgrades, and steady state ops.