In a recent blog post, data management company Segment describes how it had joined the microservices architecture movement, which was led by heavy hitters like Amazon, eBay, Netflix, Uber, and others. Even while the press was reporting how these high-tech business giants were having great success with this architectural approach, Segment was discovering that using microservices has quite a few downsides.
The company describes its flagship product as a customer data platform that collects and forwards data to any location and to over 200 tools in real time. It also offers an HTTP Tracking API that records data analytics from any website or application.
Segment defines microservices as a collection of server-side applications constructed by combining many single-purpose, low-footprint network services. The company cites as attractions the improved modularity, reduced testing burden, and other benefits, as compared to the monolithic architecture, which is a single service that must be developed, tested, deployed, and maintained as one unit.
Over time, Segment's developers found that instead of gaining greater control over the company's development and maintenance of its core platform, they realized they had begun juggling the pieces, becoming "mired in exploding complexity," and seeing any benefits of microservices disappear as the team grew increasingly overwhelmed.
Segment made the switch to the monolithic approach, which improved operations tremendously. Its developers do acknowledge they've had to let go some of the benefits microservices, including simplified fault isolation, more effective in-memory caching, and addressing problems in multiple destinations when updating. But turning to the monolithic architecture let them catch up with solving operational issues, allowing them to regain their forward-moving productivity. However, Segment developers knew the change in approach meant they had to ramp up and expand their testing if they worked with only one repository.
Segment discovered the limits and the benefits of developing in two software architectures, an experience that in the end served them well. The company learned a tremendous amount about its products, its team, its work methodology, and perhaps most importantly, how to best set and achieve its goals.