St. Louis, Missouri. Orleans, France. The Hot Gates, Greece.
Throughout history, certain places have been anointed with the term “gateway to the _____.” These locations are famous for being strategically important to either the defense of a kingdom – France, Sparta – or as the beginning of an expansive effort to settle new lands – St. Louis. Gateways are places that lead to somewhere else, usually someplace important. If you control it, you control who or what comes in (or goes out). They provide control over access as well as affording a more efficient point of protection against invasion or attack. In the modern world we see these gateways at airports around the globe when we’re required to traverse “customs” in an international airport or have to pass through the dreaded “security” to enter in the first place.
It is no surprise, then, that a group of devices has arisen in the course of technology’s history that are considered strategically important and are known collectively as “gateways.”
In the case of applications, these devices (that occupy a strategic point in the architecture), provide for security, scale, and often interoperability, of emerging technologies.
Loosely, we could deem the network firewall as “the first” instance of an app-centric gateway in the network. Back in the early days, they were the gatekeepers, after all. Apps could only be accessed from outside the corporate network if the network firewall allowed that access. Today’s gateways, however, are far more application savvy and address not only the need for security, but scale, access, and interoperability, as well.
All are key concerns as we ramp up into the era of IoT. A recent HCL survey conducted by Vanson Bourne found that 93% of respondents were concerned about security, 86% about scale, and 83% about interoperability. None of this should be surprising. The sheer volume of devices needing access to apps to collect data, exchange commands, and monitor things is sure to have an overwhelming impact on any network. The speed with which firms are pressured to get the next “thing” to market has a deleterious impact on security. And interoperability is always challenging in a new market that is reliant as much on communication with other things and apps as it is performing its intended use. Nascent markets tend to diverge quickly and pockets coalesce around a variety of standards until one day, we settle on one or two. But early on there is often a complex and confusing set of choices. Innovators are unwilling to wait for the dust to settle. Innovators win, after all, by getting to market.
The issue then becomes how to address security, scale, and interoperability while the emerging technology is maturing and standards are being hashed out. The answer to that is, generally, gateways.
In the past, gateways have arisen to deal with the same challenges around other technologies and protocols such as XML and SOAP. I’m not the only one who will remember (and perhaps cringe) at the fisticuffs between RPC/ENC and DOC/LIT as the “standard” for web services. And I’m not the only one to recall the more recent battle between JSON and XML. Today, those tug-of-wars are occurring in the IoT arena, where MQTT and CoAP and AMQP are vying for ascendancy.
Innovation can’t wait, however, and gateways are emerging left and right to deal with challenges arising from new technologies and protocols.
HTTP2 gateways primarily address a challenge with interoperability between HTTP/1x and HTTP/2. These devices terminate HTTP2 on the “outside” in order to support mobile and IoT devices that perform with greater alacrity when using the most recent HTTP standard. They enable innovators to provide support for HTTP2 to consumers and things without the massive disruption required to upgrade app and network infrastructure to support the new standard. Certainly it is hoped (expected) that one day everyone will be running HTTP2, but in the mean time, HTTP2 gateways provide the interoperability necessary for innovators to move full steam ahead.
The emergence of API gateways is akin to that of a butterfly emerging from a cocoon. It was a caterpillar (SOA gateways) but now it’s a butterfly (an API gateway) instead. Now, that’s not to say that there aren’t brand new entrants to this category – there are – but they do share a great deal of similarities primarily because the foundations of both reside in HTTP. Where SOA gateways were primarily concerned with XML and SOAP, API gateways are focused on JSON and RESTful APIs implemented using HTTP endpoints.
These devices provide security and scale, and in some cases interoperability services. They’re fluent into the language of apps, speaking JSON and HTTP with equal ease, and provide a strong foundation for supporting emerging app models like microservices and serverless that can distribute API calls not just across applications but environments, as well. API gateways also serve to protect scalability by enforcing quotas (rate limiting of calls) as well as controlling access via API key management.
These are not just “load balancers”, though scale through load balancing is certainly a key characteristic of API gateways. These bad boys must be able to go beyond plain old load balancing to enable a consistent consumer-facing experience while simultaneously enabling developers and businesses to take advantage of cloud and serverless. API gateways need to be “smart” if they’re going to secure and scale APIs, which means being able to inspect requests and responses as well as integrate with external authentication providers like OAuth2 and JWT.
IoT gateways are the most nascent of the gateways today, but they are out there and they’re vitally important to the success of IoT initiatives, perhaps more so than that of other gateways to their respective markets. This has to do with the protocols, which are not at all web-friendly protocols. While many consumer gadgets do speak “web”, it’s more and more the case that thing-makers are relying on IoT specific protocols like MQTT and CoAP because they are more efficient and consume less compute on the device. But the apps that receive that data don’t necessarily speak MQTT and even if they do, they can’t scale on their own to meet (hopefully outstanding) demand.
So arises the IoT gateway, which is fluent in the languages of IoT and the web, and can scale and secure access at the same time. These gateways, like API gateways, need to be “smart” enough to translate and route requests and responses as well as detect anomalies or bad behavior to prevent exploitation.
Architecturally, gateways provide access to networks and applications. Requests are funneled through them, making them a strategic point of control at which access can be controlled, translations provided, and security enforced. They are a key enabler of new technologies as they afford organizations the ability to innovate during the natural transition period that occurs when any new technology or protocol emerges with less disruption and risk to existing business and apps.
While gateways tend to be viewed as architectural constructs they are just as frequently today key enablers of innovation that enable business to harness the power of emerging technologies.