Monolithic versus Service Oriented

Software development has been through a tremendous change over the last decade. A new central point has become the Application Programmable Interface (API). This is a way to connect two systems together and allow them to exchange information. API's have always existed but are now more central than ever as the cloud grows and developers can connect multiple API's more easily. Within a single application you can have API's too, like modules that provide an interface.

This article will provide a detailed look into the Service Oriented Architecture (SOA) to see if it can be applied to Awesome Industries (a generic SaaS company) and what the advantages are.

What seems to be the problem?

As a startup you want to create a Minimum Viable Product (MVP) as fast as possible. This product contains only the core features and nothing more. If your customers are happy and the product seems to work, you extend it with more features and let it grow naturally. This will allow you to produce a product faster and gather feedback along the way. You just build as fast as you can without thinking about the architecture of the application too much. Because if the idea doesn’t work you have done all that work for nothing.
By following this approach you might end up with a monolithic application. A monolithic application is a single tiered software application that fits the user interface, data access and business logic into one system. It is therefore self-contained and independent. This works fine when you have a small team working on the product but as your team grows this could be a problem.
If you have over 20 people working on the same files they tend to get in each other’s way. Every developer makes changes to the software and this must be merged before a stable release can be made. If they don’t communicate enough this might lead to a break in the system. As the application is monolithic and responsibilities are not divided this means the entire application will go down. Another problem occurs in the performance as there is no way to perform operations concurrently. Everything is processed by one system and that can not go multithreaded or in parallel. Lack of clear ownership is a common problem within growing teams. Over 20 developers are building new features and everything goes great, until a problem occurs in the system. Who is going to solve it? As there are many features merged into one application its unclear who takes ownership of this product. Its just too big.

Lets take an example

Awesome Industries is a online platform and also relies on the monolithic application approach. The original product was fairly simple and got extended over the years. As the development team grows to over 20 members, it is time to look into new approaches. One of them is the Service Oriented Architecture (SOA). Service Oriented Architecture is a software design pattern based on self-contained services providing functionality to other applications. Every service is therefore independent. This way you can let different teams work on different services simultaneously. Every service will have their own roadmap, deployment schedule and codebase.
Awesome Industries consists mainly of one codebase with all the storage, presentation and business logic in there. The key features need to be cut out and moved to a separate codebase and reachable through a service interface (API). When designing this interface you must keep in mind that one day this service might be opened up to the outside world for 3rd party developers to use. This means it needs to be logical, simple and well documented.
In the image blow you can see the current monolithic architecture present at Awesome Industries. In this architecture the following problems occur.

• Poor concurrency
• Getting in each other’s way
• Lack of clear ownership
• Leaky abstractions / tight-coupling

When looking at this architecture, it doesn't quite end here. We offer this in three different places. There is the frontend, where people see their website and can browse pages and pictures. There is also a backend, where the customer can manage their website and edit content. And lastly there is a API for third party developers to create apps with that they may sell in our App store. The business logic is now copied to three locations and must be maintained in each of them. This is a nightmare.

We can slowly start to break small pieces off these applications and move them to independent services. Let take the price calculation for example. A product has a base price that can be affected by quantity discounts, discount rules, a voucher code, the country of destination and much more. It has too many complex calculations and we keep adding new features to it. Instead of having this in three locations we could create a “Price calculation service” that will take care of everything. It may be accessed by the frontend, backend and the API.
In the image below you can see an example architecture of how the Awesome Industries system could look like.

Success stories

Amazon changed their view on services back in 2002. The CEO sent a mail to all the staff saying that from this moment on every team will henceforth expose their data through the use of services. Only accessible through documented interfaces. They must be built from the group up to be exposed to the outside world. Anyone who fails to do so will be fired.
Over the course of the new few years the team started working on this and with great success. Amazon today is one of the most service oriented companies and made a tremendous growth by allowing developers to use their services through API’s. In fact if you look at the predicted revenue (image below) for Amazon Web Services in comparison to Microsoft Azure and Google Compute Engine they are way ahead.

This is only the revenue stream and the size of their cloud can not be determined from this just as the cause of their success is not per definition tied to the way they adopted SOA, but it is very interesting to see how successful a 100% SOA company can become.
All major companies like Google, Facebook and Twitter have also adopted the SOA approach. Twitter has published a video where Jeremy Cloud presents the way they decomposed Twitter into a SOA architecture. Their initial problem shows a lot of resemblance to problem we currently face at Awesome Industries. The image below shows the architecture of Twitter back in 2006 where all of Twitter consisted of 1 monolithic application.

One of the biggest problems Twitter faced was way the system was coupled. It was so tight that when one small part would fail, the entire application would go down. He named a example of where they added a Japanese translation that brought the entire site down.
At one point there were over 100 developers working in one codebase. It took them weeks to get a stable build out the door and even after this period the build wasn’t stable enough.
One of the most interesting things Jeremy mentioned in his talk was the way they approached this transition. He made an interesting statement.

“Incremental change eventually wins” - Jeremy Cloud from Twitter

If you want to make a really big change, you can increase your chance of success by making many small changes. A couple of times at Twitter we tried to do something big, where we put our heads down for 6 months trying to build something really big and then bring it up at the end. And invariably that approach is gonna fail. Things on the ground change within that timeframe.

There's a basic recipe to this approach. A sort rule of thumb.
1 - Make the smallest possible change you can make
2 - Verify that it works and tweak it
3 - Goto step 1

Do this over and over and over and with each step you give yourself the chance to do course correction and this is the critical part. If you're watching where you're going the whole way and you're making course corrections, you can minimise the risk at each step and you're more likely to reach your destination. This rule of thumb applies to basically all the phases of the software development lifecycle. Now when implementing SOA at Awesome Industries we will use this rule of thumb to guide us through the process.

Services in more detail

Services can not hold any state, they must therefore be stateless. They must not require knowledge or any internal structures or conventions (context) at the client or service side.2 In the current Awesome Industries architecture that state is stored on all the application servers. All copies are identical so every server has the same state. This makes it rather difficult to scale up since every new server needs to receive the new state as well. For services to work this state must first be moved to separate servers to allow the application servers to be stateless.
Ownership and responsibilities can now be easily drawn. One team will be in charge for one or more services. They provide end-to-end support and maintenance for these services. When an employee is not part of this team he may not change the service. If a team needs changes in the service operated by another team they can send in a service request for operational change. This team can then plan this maintenance in and work on it in a structured manner.
Concurrency is also crucial for applications to improve performance. This means running services in parallel. For example when a new order is placed, the payment- and shipping process needs to be handled. Also the customer details need to validated, processed and the customer needs to be notified. When this is done in a procedural manner this could take a while. But in parallel it may be way faster. With separate services handling these tasks you can improve the concurrency.

“One damaging assumption for service is that it is another term for component. Many of the good practices that were expounded in component-based development and integration methodologies are relevant but services are freed from the ties to platform or language specific technical frameworks”

Be careful not to make the same assumption. A service is just like a standalone application that must run completely on its own and does not have any shared storage.

Conclusion

Service Oriented Architecture is mature enough to be implemented in production environments. Many international corporations have already done so as SOA has many advantages over the monolithic approach.
In the world of fast growing startups you can not run behind. One way of ensuring your growth is implementing SOA as we have seen and heard from many sources. Awesome Industries is ready to adept. Over the next year we will start implementing this new approach with the tips and guidelines as set by the big companies that have completed their implementation.
It will not be easy to change the foundation of a running system running over 10.000 customers but the cost of not implementing will definitely be higher. Slow and steady our system will adapt.