First off: I am not a zealotous proponent of maximum microservices. There are problems galore in constantly changing services that are also interdependent on each other. But the sheer number of bad microservice posts trying to detail what they are and why they have cache is astounding. It isn't that hard, people.
Most of these bad introductions starts at the software/component/design level, trying to compare architectural diagrams or styles, and contrasting with "monolith" architectures. ...Totally misses the main point of microservices that drives their benefits and values. Microservices fundamentally don't
Microservices are small in the sense that they are easily integrated atomic unit into modern cloud/devops/infrastructure-as-code/DatacenterOS computing and continuous delivery platforms. That is a microservice: whether it's a small VM, a docker image, jails/LXC, whatever. They are easily provisioned, deployed, relocated, and redeployed on these platforms.
Microservices plug into continuous delivery and version control systems with automated testing and immediate deployment to at least qa/staging environments once the build passes (and rapid deployment to production once the tests pass). Because they are "small", the incremental builds are relatively quick (an hour or two tops) even though they use lots of modern code coverage, code quality, code formatting, automated testing, automated deployment, and similar tasks beyond simple compilation.
Here are things that start to make your code not-microservice:
- proprietary software: There's a reason microservices are built to the wazoo on open source software. License servers, license acquisition, audits... always introduce a screeching halt to devops. Sure that can be bolted on, but there often are even more insidious things that get in the way: poor command line tooling, over-reliance on UI configuration, hidden "consultant bombs" and obfuscated documentation that prevent you from efficiently making a continuous integration pipeline or versioning your code with it.
Part of the small code and huge numbers of servers in microservices actively defends against the insidious influence of proprietary software salespeople: Sure organizations will buy 10 or even 100 licenses. But 10,000 Websphere licenses? Forget it. Microservices by preempting proprietary software enables scaling down the line. A definite feature in most circumstances.
- manual deployments: I get you might need a production approval process in many situations. But if each deployment requires some ticket to be filed and fingers drummed on a desk while you wait for some long list of manual tasks to be performed... forget about it.
- hardware starvation: while hardware costs shouldn't be ignored, if your organization can't deploy a $5,000 server without $50,000 of meetings, approvals, and documentation, or if your "cloud" is constantly running out of servers and disk space to power your software, then you can't do microservices. The devops platforms it depends on require sensibly budgeted hardware that can handle new services. That doesn't mean a small piddly service needs a quad-core processor and 4 gigs of ram. It means that the autodeployment step in the continuous build only fails due to hardware shortage once every few months, and that is fixed within a day, tops.
If your huge 1,000,000 line "monolith" legacy service can be fit into the above: containerized, continuously delivered, and deployed within a few hours of pull request or some similar software change, then congratulations: you are a elite microservice team.
- multiple organizations served in a codebase: Per Conway's law, your software WILL align with your business organization. Some of the problems of the big monolithic ERP software was to couple disparate business divisions in the same system. So programmers maintaining software couldn't find the parts of the monolith they needed when they were inevitably aligned with some business function. Microservices help keep enterprises' custom software isolated in specific functions that can be documented and maintained more easily. If some function is to be reused (but inevitably... slightly... different) across organizations, microservices should implement the shared model, and then write dependent services for the specific organization variants.
Most of these bad introductions starts at the software/component/design level, trying to compare architectural diagrams or styles, and contrasting with "monolith" architectures. ...Totally misses the main point of microservices that drives their benefits and values. Microservices fundamentally don't
Microservices are small in the sense that they are easily integrated atomic unit into modern cloud/devops/infrastructure-as-code/DatacenterOS computing and continuous delivery platforms. That is a microservice: whether it's a small VM, a docker image, jails/LXC, whatever. They are easily provisioned, deployed, relocated, and redeployed on these platforms.
Microservices plug into continuous delivery and version control systems with automated testing and immediate deployment to at least qa/staging environments once the build passes (and rapid deployment to production once the tests pass). Because they are "small", the incremental builds are relatively quick (an hour or two tops) even though they use lots of modern code coverage, code quality, code formatting, automated testing, automated deployment, and similar tasks beyond simple compilation.
Here are things that start to make your code not-microservice:
- proprietary software: There's a reason microservices are built to the wazoo on open source software. License servers, license acquisition, audits... always introduce a screeching halt to devops. Sure that can be bolted on, but there often are even more insidious things that get in the way: poor command line tooling, over-reliance on UI configuration, hidden "consultant bombs" and obfuscated documentation that prevent you from efficiently making a continuous integration pipeline or versioning your code with it.
Part of the small code and huge numbers of servers in microservices actively defends against the insidious influence of proprietary software salespeople: Sure organizations will buy 10 or even 100 licenses. But 10,000 Websphere licenses? Forget it. Microservices by preempting proprietary software enables scaling down the line. A definite feature in most circumstances.
- manual deployments: I get you might need a production approval process in many situations. But if each deployment requires some ticket to be filed and fingers drummed on a desk while you wait for some long list of manual tasks to be performed... forget about it.
- hardware starvation: while hardware costs shouldn't be ignored, if your organization can't deploy a $5,000 server without $50,000 of meetings, approvals, and documentation, or if your "cloud" is constantly running out of servers and disk space to power your software, then you can't do microservices. The devops platforms it depends on require sensibly budgeted hardware that can handle new services. That doesn't mean a small piddly service needs a quad-core processor and 4 gigs of ram. It means that the autodeployment step in the continuous build only fails due to hardware shortage once every few months, and that is fixed within a day, tops.
If your huge 1,000,000 line "monolith" legacy service can be fit into the above: containerized, continuously delivered, and deployed within a few hours of pull request or some similar software change, then congratulations: you are a elite microservice team.
- multiple organizations served in a codebase: Per Conway's law, your software WILL align with your business organization. Some of the problems of the big monolithic ERP software was to couple disparate business divisions in the same system. So programmers maintaining software couldn't find the parts of the monolith they needed when they were inevitably aligned with some business function. Microservices help keep enterprises' custom software isolated in specific functions that can be documented and maintained more easily. If some function is to be reused (but inevitably... slightly... different) across organizations, microservices should implement the shared model, and then write dependent services for the specific organization variants.
No comments:
Post a Comment