Separate concerns in large scales computing by leveraging different types of services in the cloud
The history of computing reveals different eras starting from mainframe to client/server to Web computing. With mainframes, computing is contained within the boundary of a mainframe. With client/server and web computing we see the separation of the presentation from the data. With all these computing models, the data is owned and maintained by different applications. The IT staffs who run and maintain the applications are responsible for backing up and maintaining data.
With the rise of cloud computing, I see a new trend that will fundamentally change the game and push productivity to all new levels. I call this “Aspectual Centralization” (AC). This is as important to cloud architecture as Model-View-Controller (MVC) is to software architecture.
With AC, different aspects of an application are extracted out and delegated to centralized services: data services, messaging services, logging services, and so on.
This extraction and delegation process has two profound impacts on application development and deployment. First, application architects and developers are freed from designing these different services, and can really focus on the application business logic instead. Having said that, you still need to design your data schemas.
Secondly, the IT staffs that run the application will not worry about data backup anymore. Backup and maintenance are still needed but this activity now shifts to the staff maintaining centralized data services.
As you can see, this accelerates the IT trend of staff specialization with commensurate gains in productivity.
This specialization works best for big IT shops. But what about smaller ones? For one thing, your IT staffs may have to assume multiple roles. But the clear defined role and responsibility will improve productivity as well. If possible, you can leverage external service providers for data services.
For implementation, you can offer centralized services with traditional physical servers, or go with virtual servers. In the latter case, you will have dedicated virtual machines for these services.
Use AC to:
1. Centralize common services and manage them effectively and consistently;
2. Scope out basic infrastructure from application development;
3. Build applications based on enhanced service-oriented-architecture and enforce it across the enterprise;
4. Improve efficiency of IT administration therefore reduce OPEX.
While gaining many benefits from aspectual centralization, you may face these challenges:
1. Initial investments on the enterprise wide services and re-factoring of existing systems may require additional CAPEX. This could be mitigated using external service providers or virtualized infrastructure.
2. Performance of individual applications may be affected with remote access to other services. Local caching may be required which may complicate the system and defeat the original purpose.
3. It’s harder to cut the boundary of individual applications, which are interwoven into the whole infrastructure. If you are interested in a particular application, it’s easy to move it around inside an enterprise but could be hard to move elsewhere without moving the whole service infrastructure.
Some service providers provide various data services like Amazon’s S3/SimpleDB, Google’s BigTable, Microsoft Windows Azure Storage/SQL Azure, or messaging services like Amazon Simple Queue Service (SQS). You can use these services either from your applications running in their data centers or in your own.
For enterprises, it’s long been an acceptable practice to share databases across different applications, but generally not as common services. The AC architecture pattern will be widely adopted as we move on to IT as a service paradigm.
Stateless VM: You can use stateless VM but still persist your data with AC.