Scalable deployments - Choosing middleware components
Different user groups have different performance expectations from a system they're involved with. Given a platform, be it a middleware/application development or integration, there are 3 sets of stakeholders we can consider,
Developers always want the platform/tools they're working with to be robust. Some developer expectations include,
A robust platform applications can be developed and deployed with minimum effort and time.
Use of different 3rd party libraries to ease development as much as possible. When library usage increase, available resources for shared tenants goes down. No amount of autoscaling can solve uncontrolled library usage
Fast service calls regardless of business logic complexities in services. Sort of ignoring the network boundaries/external DB and system calls. Another aspect is when more stricter security measures are utilized, more time spent for processing security related headers, thus reducing response times.
Fast application loading times when the applications grow in size and complexity. Without designing the application to keep a low footprint, or process large data chunks efficiently, underlying platform cannot solve this. When size and complexity of applications grow, autoscaling times of instances will also increase.
Operations or deveops folks have a different set of performance expectations from a platform.
They want instant instance spawning and start up times.
Fast log collection. This can be collecting platform level logs to identify performance problems as well as collecting application level logs for  developers.
No sane devops folks want to manually deploy a complex system. The entire deployment should be automated.
Seamless autoscaling of services from the deployment itself without having to wait until one server gets bogged down and do some manual patching.
Available resources should be equally distributed among active nodes for efficient utilization of shared resources.
Customers are probably the most difficult lot to please. Quoting from The Guardian article based on Mozilla blog of metrics,
32% of consumers will start abandoning slow sites between one and five seconds
So applications exposed to customers should be fast and have short response times.
Users expect application developers to write fast responsive applications. App developers look at devops/operations to provide a scalable platform for their apps. Devops in turn rely on architects to provide a robust deployment architecture that scales based on application requirements.
Expectations on architects are,
Identify and use correct reference architecture/s
Use correct deployment architecture based on application requirements as well as non functional requirements
Deployment architecture should be aligned with business expectations of the system
Should take SLAs into account
Identify correct SOA/middleware components for the business use cases involved
Getting the right architecture
Identifying the right SOA components is an important step. In a typical middleware stack there are multiple components to choose from. Usually each component have very different performance characteristics. There are many ways to implement the same scenario.
Let's see a simple example. Scenario - withdrawing money from a bank. This can be implemented is several different ways.
Example - Method 1
Here this can be implemented as a web service or web application which talks to a DB and host it in an application container
Example - Method 2
This example expose DB operations through Data Services Server, use an ESB for doing mediation and then expose an API for withdrawing money.
Example - Method 3
In this example, there's a Business Process Server orchestrating the process. There are Business Activity Monitor for monitoring business transactions and Governance Registry as a repository.
A given scenario can be implemented in many ways and also the complexity and use of components will vary. Based on the scenario in hand, right components should be selected.
