Microservices - same as it ever was?
CTO Summit
Innovate, collaborate and transform. The world is constantly evolving, and it's always great to have the chance to meet with leaders with a purpose interested in making the world a better place. So I'm living life with an attitude of gratitude. A big shout out to everyone at Q Connects, especially Alex! They specialize in networking and building relationships within Southern California to connect top talent in the Technology Industry.
They hosted a C-level executive dinner event last week at Spago in Beverly Hills (how nice is that?!) featuring an experienced and diverse panel on the subject of “Microservices - from Inception to Monitoring and Everything in Between”.
Note 1: I think Martin Flowers description of microservices is a great resource for this subject.
Note 2: One reason I'm writing about microservices is that I'm working on a proof of concept project integrating two monolithic applications (with a shared data layer) into a discrete set of microservices to support a new pricing model for the business.
Microservices - a little background
Microservices are currently getting a lot of attention right now. For good reason. A microservices architecture pattern has significant benefits – particularity when done in conjunction with agile development and the delivery of complex enterprise applications. There are always rock throwers in any technology crowd, however, and one of the rocks I see frequently hurled at microservices is that it is neither novel or new. Rather a re-branding of sorts of the service-oriented architecture (SOA) pattern. I'll let you decide on that one.
All aboard the Monolith express - next stop: the unemployment line
One thing I hope we all agree on is that Monolithic applications poses certain constraints on developers. And they can be exasperated in the modern web based world. Need to make a change to the UI to enable the dynamic filtering of data? Rebuild, republish and redeploy. Oh, and by the way could you do that without disrupting service? Yeah, like changing the tires on the bus while it's moving. No simple task.
My personal experience, based on several decades of software development and engineering, has taught me that most applications, once they have been launched and become successful in the market place, have two pathways. It grows, which means more code, more functionality, and increased complexity. Which means less flexibility and longer development cycles. Or it dies. Neither one is very pleasant.
But my biggest gripe against large, complex monolithic applications is that no one person (even the world's most brilliant technologist) can fully understand the entire beast. In the modern world, it takes a village to raise an application. By breaking down the complex world of system architecture and application programming into smaller more discrete objects, I can help in areas when and where I need it.
All the cool kids are doing it
Or should I more accurately say, all the smart kids are doing it. Some super successful companies, like Netflix, eBay, and Amazon have thrown their hat in the Microservices Architecture pattern ring. Instead of building a single humongous, unwieldy, monolithic application, they are pursuing the of splitting large applications into set of smaller, interconnected services.
Summary
So here's my plan: for now. A distinct set of feature such as user administration, portfolio management, and online product management will be implemented as a service. Each service will be a kind of mini-me application containing the business logic and various adapters. One set of services will expose an API that is consumed by both internal and external clients. At run time, each instance will be either a cloud VM or a Docker container.
Wish me luck, and I'll do the same for you. May the force be with us all.