Enterprise applications no longer live in one place or service a fixed office or region. We have long entered the era of extreme mobility and the age of the road warrior. Question is, how do you cope? How do you get your applications to scale and meet the ever growing demands on it? The answer is simple. Enterprise applications cannot afford to have a home anymore!
Road warrior. The first picture that comes to mind is of a heavy rifle touting movie hero sauntering down a sun-beaten black-top road, possibly a dog at his side. Tumble weed blows across the road around him. The task of the office-going road warrior is no lesser. Instead of guns and ammunition, our road warrior carries an ever burgeoning bundle of gadgetry. Instead of walking, he or she may be ensconced in a comfy air-conditioned car or jet plane. This is your “customer” today for the enterprise application humming away in the unknown corner. To rephrase a cliché, your colleague, partner or user may login to the application from New Delhi, work on it on a quotation sitting in a café in Singapore, send it to his boss from an airplane flying over the azure seas of the Mediterranean, and finally close the deal over dinner in New York two nights later. Now imagine a few hundred such road warriors of your organization moving around the globe simultaneously, or applications like Facebook or Linkedin.
As usage grows, the application has to scale. Traditionally, scaling meant moving the entire application from local server to datacenter to cloud. This requires serious efforts in re-architecting as well as rewriting the application and in moving it around. The way around this is to use loosely coupled deployment architectures from the start.
In a loosely-coupled deployment architecture, applications are built as a group of components. Each component can be deployed anywhere (local machine, different server, different location, cloud) independently of the other components. This type of architecture lets your application scale up massively, while supporting extreme component reuse.
There are some basic issues you need to keep in mind while designing loosely coupled component based architectures. We will discuss these issues in this introductory piece.
Once upon a time, the host platform for an application was simply about the operating system it would run on, and then it became about where that machine resided -- locally on your premises or in a dedicated data center. In the first decade of this millennium, virtualization brought in sharing of resources. The decade after that, it has been all about getting it to the cloud.
Enterprises have long since taken the “outsource” mantra to move away from areas of operations that does not fit into their core business. Many enterprises do not even run their own IT, much less have their servers locally on premises, except for some proxies and caches. Effectively, today, the choice of where to run something from is between hosting it in a data center and hosting it in the cloud.
Design simple, design to scale – Modules!
Modular design is “in” today everywhere from the way we build our furniture to cars to space ships. And that is how it should be for software too. The idea is to build applications as modules that can readily come apart. Note though that I am not advocating a “lose coupled” architectural design – that is an entirely different discussion. (“Loose coupled architecture” is when each component has no idea what other components may be connecting to it, or itself may connect to). What I am advocating is that these modules should not care about where they live. Different combinations of the modules can follow loose or tightly coupled architecture.
This way, some parts of your application could actually end up in that dusty 1990s PC in your basement, and others may end up on free scaling nodes hosted on some cloud service. The magic is; the very same components can be installed with little or no changes (ideally only configuration changes) on that dusty PC and they should still happily work out of it, barring scale and other resource issues.
Roles, not tiers matter
The smallest of enterprise applications have at least two “tiers”. A tier is a distinct encapsulation of a kind of service. For example, if you take the user interface (UI) of your application, that is one tier. The data storage is another and so on. But our applications have grown way beyond such pithy definitions. Today we talk about elastic and virtual networks, virtual machines, roles and different types of clouds, mash ups, social media and what not.
Today’s application components are described in terms of the “roles” they play. For example, a user interface is a role, a database is a role, and a background-running service is a role. You can have more than one of each role (for example you can have two databases in your application). But you can never have more than one component in each role. Your deployment (runtime) architecture should be based on the role of each component.
Languages and Tools support modules
There are a ton of new coding languages out there: Node.Js, MVC, MVVM, REST API, Json… Even among these technologies there exist subsets and “ports” and equivalents that try to make the technology function across a broad spectrum of host platforms, operating systems and other environments.
Typical applications of scale today rarely rely on a single technology or language or even a family of technologies or languages. This is mainly because they in turn need compatibility to interact with other services and components that are built or support only a particular type of interface or data format that one technology is a specialist in.
Your architect’s “abracadabra” then is the least common denominator of technologies. When you use the smallest subset of technologies, viz. languages, toolkits, SDKs, and so on, that is supported across the diaspora of application hosts (data centers, cloud, etc.) then your application is insured towards “loosely coupled deployment” architecture.
Challenges with multiple cloud platforms
Microsoft has Azure, Amazon offers AWS, Google has Apps, Apache CloudStack. There are 71 cloud platform providers listed on this Wikipedia page: While each provider has their own USP and set of services you may find useful for your needs, if you do decide to spread your bets among a combination of them, would they really interoperate and play nice? Different flavors of Linux or Windows or even home-brew operating systems, layered over with custom “cloud” software, management tools and API make the game murky. While typical “websites” may work fine across them, think about data, data services and web services.
A key consideration for enterprise application components of these categories is security. For example, if there is this really good security model you can use to secure your web service on Azure, will the consuming endpoint on Amazon VPC provide a complementary way to work with it?
You may very well need to re-draw some portions of your code (especially the interfaces between different modules) to take care of these problems. You may also need to build in support for more than one way of doing things.
Some things are just not possible
Finally, decision makers in the organization will sometimes have to accept that some things are just a tall order and are either not practical for some reason, or just not possible at this point of time. The decision to put something on a certain hosting platform must be taken with care and in consultation with all relevant stakeholders (including engineering and operations).
In future articles, we will explore actually taking local applications and scaling out to the cloud.