3 ms·

Wow I remember when this was published and such a good rant. Had to read again for laughs. SOA is sort of the older term... a subset which is a better descripti

Wow I remember when this was published and such a good rant. Had to read again for laughs. SOA is sort of the older term... a subset which is a better description of where platforms should be heading is microservices. Issues like rate limiting still exist but need to get away from things like api gateways as well as they are becoming a sort of antipattern for scaling massively. They're useful for certain problems but not necessarily as useful as lower level message queuing engines that need to handle high volumes of transactional throughput.

philwelch 8y ago
The biggest difference I’ve seen between SOA and microservives is that people have been able to explain to me what SOA means. Aside from that, the term “microservices” implies a bunch of anti patterns in itself, and brings to mind horror stories of startups with three times as many microservices as engineers that invested multiple man-years in setting up Kubernetes to do something that could have been accomplished with a fraction of the cost in 2005 with ASP.NET and Microsoft SQL Server. Service boundaries are significantly more expensive than people assume. A monolithic web application, or even a “macroservice”, can still be scaled horizontally with network dependencies on a shared database and can call any code or access any local data with the same basic guarantees of any other computer program. Your procedure calls are normal procedure calls, whose contracts and interfaces are as efficient and safe as your language’s type system allows. You can have unit and functional test coverage that exercises virtually all of your feature or application without needing to deploy and integrate multiple services. You can achieve better focus and deeper investments in infrastructure when there are fewer services to deploy and support. The only issues with concurrency and distribution you have to worry about are whether you are writing threadsafe code in the first place, your connection to your database, and perhaps cache invalidation. The minute you introduce a service boundary, you throw all of that away. API calls have to be documented, versioned, and validated on both sides. Tooling exists for this (Swagger, gRPC, GraphQL), but the complexity is much higher. Testing requires deploying interdependent services in a shared test environment. Your service interfaces have to be built with some well-considered strategy around resiliency and consistency because you might (and, with enough services, statistically will) have to keep running with some unavailable dependencies. Even dependency management, which is already a hell in itself, becomes combinatorially harder when you have to design around the requirement that your service dependencies (and the services that depend on yours) can change at runtime with you being none the wiser. Now, at times, you don’t have to incur all these costs. Some services are inherently independent. Some behaviors can and should happen e.g. on a message queue or on a schedule rather than in response to live traffic. And, at a certain scale, you need to separate your data stores, decouple your feature deployments from each other, or reap many of the other benefits of SOA. But those benefits aren’t free; they’re extremely expensive, and companies on the scale of Amazon or Google reap those benefits not because they are inherently wonderful, but because despite the costs, they are the only way certain things are possible in the first place. If monoliths are the communist planned economy of web applications, SOA are the market economies. They can scale a lot, lot more, but at the added overhead of everyone having to squint at each other suspiciously and distrustfully.

philwelch 8y ago

The biggest difference I’ve seen between SOA and microservives is that people have been able to explain to me what SOA means. Aside from that, the term “microservices” implies a bunch of anti patterns in itself, and brings to mind horror stories of startups with three times as many microservices as engineers that invested multiple man-years in setting up Kubernetes to do something that could have been accomplished with a fraction of the cost in 2005 with ASP.NET and Microsoft SQL Server. Service boundaries are significantly more expensive than people assume. A monolithic web application, or even a “macroservice”, can still be scaled horizontally with network dependencies on a shared database and can call any code or access any local data with the same basic guarantees of any other computer program. Your procedure calls are normal procedure calls, whose contracts and interfaces are as efficient and safe as your language’s type system allows. You can have unit and functional test coverage that exercises virtually all of your feature or application without needing to deploy and integrate multiple services. You can achieve better focus and deeper investments in infrastructure when there are fewer services to deploy and support. The only issues with concurrency and distribution you have to worry about are whether you are writing threadsafe code in the first place, your connection to your database, and perhaps cache invalidation. The minute you introduce a service boundary, you throw all of that away. API calls have to be documented, versioned, and validated on both sides. Tooling exists for this (Swagger, gRPC, GraphQL), but the complexity is much higher. Testing requires deploying interdependent services in a shared test environment. Your service interfaces have to be built with some well-considered strategy around resiliency and consistency because you might (and, with enough services, statistically will) have to keep running with some unavailable dependencies. Even dependency management, which is already a hell in itself, becomes combinatorially harder when you have to design around the requirement that your service dependencies (and the services that depend on yours) can change at runtime with you being none the wiser. Now, at times, you don’t have to incur all these costs. Some services are inherently independent. Some behaviors can and should happen e.g. on a message queue or on a schedule rather than in response to live traffic. And, at a certain scale, you need to separate your data stores, decouple your feature deployments from each other, or reap many of the other benefits of SOA. But those benefits aren’t free; they’re extremely expensive, and companies on the scale of Amazon or Google reap those benefits not because they are inherently wonderful, but because despite the costs, they are the only way certain things are possible in the first place. If monoliths are the communist planned economy of web applications, SOA are the market economies. They can scale a lot, lot more, but at the added overhead of everyone having to squint at each other suspiciously and distrustfully.