030: SOA and Microservices

What is Service Oriented Architecture (SOA)?

• In the PHP community, it is traditionally referred to as the Service Layer
• Recently, the name has changed to Microservices;
• Definition of SAO was introduced by Don Box from Microsoft when talking about WCF (Indigo project)
• 4 Characteristics of SOA:
  • Boundaries between components are explicit
  • Services are autonomous
  • Service share a schema and contract
  • Service compatibility based on policy
• Microservices seems to maintain the first two, but violate the third because they are fully autonomous

What constitutes as a Service?

• A service can be stateless or stateful
• Some examples of stateless services:
  • Image resizing
  • PDF creation
• Stateful service

Are services a web API or a daemon running in the backround?

• Doesn't have to strictly be a JSON based API, but most traditional services are
• Generally break down into 3 categories:
  • core services
  • composite services
  • API services
• API services expose your system landscape to internal or external consumers
• Core services are busy with persistence. This is where most of your business rules are going to live
• Composite services either aggregate from core services or coordinate the work of various core services.

If I use AWS for my website and use SQS to send image resizing tasks to another server, is that considered a service?

• The image resizing would be considered a service and Amazon's message queue, SQS, would be considered infrastructure

Is it true SOA was inspired by OO design principals?

• Yes. If you read the gang of four book (Design Patterns: Elements of Reusable Object-Oriented Software), everything you learn about design patterns, in general, is pretty closely related to what you do in software architecture. SOA is just a component architectural style.
• A lot of the gang of four book topics like SOLID and the single responsibility principal apply to SOA. For example, a microservice should be doing only one core business thing, etc.

Samantha's recent talk at LaraconUS

• Gave an example of a web app that used SOA. It was a website for a t-shirt company where a user could upload designs and then print the t-shirts on demand
• First explained how to build the website as a monolith where you have users, admins, various products, customer service things, order processing things, etc.
• Showed how easy it was for things to get out of control using the monolith model to build the site
• Then when into how a developer would break it up; where you might have one API to handle users, another to handle orders and customer service, another to handle products, etc.
• You can you the single responsibility principle because you can say a particular API only handles inventory and doesn't need to be concerned with users or a blog
• Slides for talk are published here
• If something seems like it doesn't closely tie to anything else, it is a good candidate to turn into a service. Worker processes are good candidates too. These things can live as their own projects and don't need to live as part of the central codebase and can be run on their own server

What are some pain points in a monolith that are an indication you need to use SOA?

• One indication is that you have a big team and you are starting to get a lot of merge conflicts
• Another indication is that you have a humongous amount of tests from a big app that takes forever to run
• One more indication is that you are constantly scaling vertically
• Unfortunately, with a monolith, it is easy to not realize that your app is too big until it is too late and you start to run into the issues above
• It can be harder to break up a monolith than to keep some of the SOA design prinicples from the start
• One barometer people use to determine when to break up their app is when the see that components in their system need to be able to scale independently
• Going back to the first point, scaling the development team is important. When breaking up the code, think about having cross-functional teams with each one owning a code base. This can bring a team size down to the Jeff Bezos recommended two pizza size, which usually makes team communication better and more productive

Is the AWS SQS image resize a good example of SOA, or are there some missing pieces?

• It is a good first step, it is a great way to "put your toes into the water"
• Doesn't solve all problems, but implementing some stateless services is a good first step
• If you decide to completely break up your monolith app, first, pull out all the obvious services,

How do you design web APIs for all your services in a way that won't make it horrible to work with?

• You should always compare tradeoffs that you are making to get the architecture you want
• You don't always need a API in front of every service.
• If you clearly define the constraints around your services, it makes it easier for you make changes underneath. It also allows you to have an easier time build your message bus between your services.

How to break up APIs by business logic?

• Think about your database schemas
• If something has a lot of FK constraints, for example orders and shipping or orders and customer service, you know that they are closely coupled and that there will be a lot of related database calls to get those resources. You might want to do it over an API, but you will start to run into latency issues.
• The more you start thinking about database schemas and relationship nesting, it is a good way to start breaking things up

How do you manage a shared set of code all your components would like to use?

• When starting out, you can copy and paste code, but you will want to eventually use Composer packages
• Composer makes it pretty seamless to keep things synced between projects
• Try not to have shared domain logic. If properly bounded, your services should not be sharing domain logic at all
• Wen components share domain logic, you are no longer clearly defining the constraints between how the components interact with each other

Are aggregates a nice place to start to look for boundaries when moving to an SOA architecture?

• Bounded context are usually more appropriate

How have you used SOA in the real world?

• Samantha: At her employer Packback, a digital textbook rental company, they have services to manage users, books, and search. They also have worker processes to gather prices and display books. They have somewhere between 12-15 services. Having experience in the monolith app world and the SOA world, it is so much easier to manage something that uses SOA than a monolith
• Sherif: Recently been working on a remote execution / eval type site. It is kind of like an educational site similar to Codecademy. This site has many services that run unit tests, makes an AST to understand code better, etc.

How are the codebases structured? Do you have a bunch of repos for all your services?

• Yes, Yitzchok's company has over 100 repos and Samantha's company is getting close

Isn't it more complicated to manage that many repos compared to one repo for a monolith?

• Absolutely from an operations perspective
• From an application engineer's perspective, you have reduced the complexity because you made what they have to deal with and think about much smaller
• From an operations perspective, you have dozens to 100s of components that have to work in concert with each other. This leads to issues with deployment, configuration management, security, message tracking, monitoring, logging, service version compatibility and many other things
• With the exception of breaking off the obvious stateless services like image resizing, PDF generation, price querying, etc., it is advised you use strong caution breaking things up, unless you have a strong Devops team
• Some things that impact how difficult managing an SOA based app depends on size of infrastructure, codebase size, number of services, weather or not Agile practices are used, etc.
• There are some 3rd party tools that can help you with the Devops complexities. In the Laravel world, there is Forge and Envoyer. There is also Blackfire.io and Newrelic that can help monitor stuff

Do you ever get confused when pushing repos, or have related issues?

• Try to go for a gated deployment
• Depending on the size of your engineering department, you can build teams around specific services, which makes it easier in terms of deployment. If one team is only responsible for one or two services, then it is less likely that they will make a mistake pushing code
• Sometimes a properly sized and organized team structure is under appreciated when building microservices
• Conway's law is pretty inescapable, so when engineers are grouped by function, for example front-end, server-side, and operations engineers, tend to do well at producing successful layer apps because they are working on a layer that they are comfortable in. But they won't do well when producing microsevices
• Typically a successful microservices team is a cross-functional squad where one person of every type on the team so that you have enough people to work from end to end on a microservice
• In your tests, just like you mock out calls to 3rd party services, you will do the same for the microservices your team uses

It seams that SOA influences how teams are structured, right?

• A small, cross-functional team per service is probably best
• If you work for a small organization or start-up, you might only have 5 people in the engineering department, so you won't be able to build teams around individual services. Just because you don't have individual teams for individual projects doesn't mean you won't be successful with SOA
• Be sure to document your services well

What about SOA and the lone developer / freelancer?

• A developer implementing a PDF generator service or something like that should be fine
• Juggling 4-5 bounded contexts where you have lots of business logic living in separate places and trying to coordinate things is probably not best for a one man shop
• If you still want to do SOA as a one man shop, you probably want to consider a 3 tiered architecture where you can have a PHP framework handling the frontend stuff. Then on the 2nd and 3rd tier, do something with SQS and talking to 3rd party services for stuff like video encoding, PDF generation, etc. This is still kind of SOA, and manageable by one person
• If you are building simple blogs for someone, then SOA is probably not the way to go
• Things like image processing for a stateless service is great for a solo developer because they are usually small, simple, and the code doesn't change often. They can be deploy and forget if well-constructed

How do you handle authentication in a SOA?

• If you are using Laravel / Lumen, you can use this Oauth 2.0 server Composer package by Github user lucadegasperi. Note: Oauth 2.0 support built into Laravel now using Passport.
• It is pretty hard to do authentication well. It is pretty easy to authenticate someone, but you have to think about security. Some things to think about:
  • How are you going to do security on multiple tiers?
  • Do you want to do end-to-end encryption on the 2nd and 3rd tier?
  • Do you want to do authentication across different parts of your application?
  • Oauth 2.0 vs some other thing?

CQRS vs SOA

• Command Query Responsibility Segregation comes out of the domain driven design world
• Are relatively orthogonal concerns in that you can do CQRS outside microservices architecture and also in complement. It is not a one or the other choice

How do you manage environment variables across multiple servers?

• One way to manage it is with Laravel Forge
• If you are sharing environment variables horizontally (like if a service is load balanced), that is cool. But if you are sharing environment variables across different services, then it might smell a little, indicating that you might not have the right boundaries
• Another option to manage environment variables is to use the combination of HashiCorp's products Consul, a service discovery tool, and Vault a key secrets management tool. Consul templates is used to publish .env files to each service. Vault is used to store the values in the .env files. The servers use the .env files to populate environment variables

Any latency issues?

• You can't escape physics, so there will always be some additional when implementing services (because it now has to make a network connection)
• Don't get fixated on HTTP as your communication protocols. Obviously, for external users, you must use HTTP, but internally, you can consider other protocols
• Consider 0MQ or some other protocol
• Latency is basically an optimization problem. There are probably other things in your app that you need to optimize first before latency becomes an issue. Probably lots of other low hanging fruit in terms of things to optimize. For example:
  • Caching
  • Getting rid of N+1 database queries

Is there anything in PHP that makes SOA better or worse? Or does it matter what language you use?

• In general, a language you use isn't the barrier to any architectural decisions made
• In terms of PHP, with its primitive concurrency model, it is kind of helpful. Mostly requests hare handled with HTTP, it is stateless, everything starts from nothing on each request, etc. This kind of helps a person think about PHP in terms of API endpoints when experimenting with SOA
• When you start to think about using other protocols besides HTTP for your internal components, then PHP could hinder you and you might want to look at other languages
• For edge components, PHP is definitely a good choice

Final thoughts

• SOA can be intimidating. But it is not really hard to get into
• Not a panacea and not a Pandora's box. Reach out to those who have done and are doing
• Microservices envy is a thing and can be a dangerous thing
• There is a marketing buzz around Microservices. Don't let it confuse you in making architectural choices.