Continued from page 1.
That said, it's certainly valuable to have a plan for breaking out various functions into separate services. You’ll need to be aware of the limitations of your system, and pick a traffic level where it makes sense to start implementing that plan, to take advantage of smooth scaling for your separate services.
UI as a Service
Treating your UI as a very simple service, even from the day one, can pay off in big ways. Calling it a service might be overstating things a bit, since many UIs can be built from completely static components. This approach can allow you to leverage CDN technologies, which greatly increase the loading speed of your UI. A quick search for 'website load speed attention span' should convince you how important this is.
Software always breaks. Whether due to a regression or a failed deployment, reducing the blast radius of failures helps to recover more quickly. The ability to deploy services independently makes troubleshooting much more straightforward. When each service does a well-defined set of things, failures are inherently lower risk, and clearly indicate the failing component. Understanding and clearly documenting the dependencies between components will help your entire team reason about failures.
Clusters of horizontally scalable, load balanced service nodes can also be upgraded one at a time, which enables zero-downtime upgrades. It's hard to overstate the effect this can have on team productivity. When you don't need a maintenance window to deploy code, suddenly features or fixes can be delivered in an hour instead of a week.
Splitting your workload up into services opens the door to independant and/or automatic scaling. If your environment allows it, you could even choose to run services on hardware that’s customized for that service’s resource needs (CPU/RAM/IOPS). Determining the limiting factor for each service lets you enable automatic scaling before services become overloaded.
Scaling is where microservices shine. This is especially true when you can pass the buck on management of stateful components. Stateless microservices can be horizontally scaled to your heart's content! Whether you choose to manage your own state, or defer to a provider of managed services, this property of stateless microservices is a benefit in several areas: the ability to scale costs much more closely with actual usage, and graceful handling of burst traffic via auto-scaling.
With monolithic systems, taking any sort of change public is a much bigger deal, and involves more time. This tends to mean that deployments containing features and fixes happen only during maintenance windows. If a bug can't be fixed quickly, its impact grows until it can be fixed. If features can't be shipped quickly and incrementally, software teams slow way down.
Velocity isn't just about deployment or execution speed however. Human factors are also important. If onboarding a new hire takes a month, or a quarter before they can deploy meaningful changes, that decreases velocity as well. Splitting things up into separate services reduces the amount of information new hires need in order to be effective. Pushing code quickly after joining a team raises morale and helps identify gaps in documentation.
The real reason we're talking about services is, of course, because people want to buy them! Finding out how your service can be more awesome for the people who use it can be a challenge. Tools that analyze how users navigate through a Web or mobile interface can help identify problem areas. Direct interaction with your users via some sort of public chat system is also extremely valuable.
Increasing your velocity allows you to respond quickly to feedback, which builds community as a bonus, when your users can tell that you’re listening. And that’s the real goal of any service, to serve a community of users!