Tracking Service-Oriented and Web-Oriented Architecture

SOA & WOA Magazine

Subscribe to SOA & WOA Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get SOA & WOA Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

SOA & WOA Authors: Andreas Grabner, TJ Randall, Lori MacVittie, Dynatrace Blog, Cynthia Dunlop

Related Topics: Cloud Computing, SOA & WOA Magazine, DevOps Journal

Blog Post

The Proxy Is the App By @LMacVittie | @DevOpsSummit [#DevOps]

How microservices change the role of the network in next-generation application architectures

Microservices, for the uninitiated, are essentially the decomposition of applications into multiple services. This decomposition is often based on functional lines, with related functions being grouped together into a service. While this may sound a like SOA, it really isn't, especially given that SOA was an object-centered methodology that focused on creating services around "nouns" like customer and product. Microservices, while certainly capable of being noun-based, are just as likely to be verb-based, that is to say, based on a functional grouping like "login" or "checkout." SOA was essentially an extension of object-oriented design while microservices are more about decomposition for purposes of rapid (agile) development with the bonus of having significant scalability advantages over object-oriented architectures.

Now, I told you that to tell you something else about the emerging relationship between proxies and applications. Or perhaps more accurately the merging relationship between the two. Microservices alone don't make an application, of course. There must be something else directing the user to the right services at the right time. That's generally what we call the "application." But increasingly that "application" is on the client, composed in the browser or using a native mobile app toolkit. What that means is a whole lot of direct calls from clients to services.

Except it doesn't, because that would be a networking and security nightmare. And neither do the local service proxies providing scale and security for those services. Because that'd still be a networking nightmare. Imagine all those services exposed to the public Internet. Consider briefly the impact on DNS, on firewalls, and on all the intermediate devices providing application services in between.

Exactly. No one does that. No one sane, at least.

There is still the need for a single "app" which represents the server-side logic in this equation.

A public interface through which requests for services are delivered, where access control is enforced, and where end-user performance is monitored and measured.

These requirements are easily fulfilled by an application proxy. It offers a single, strategic point of control that can provide the visibility, security and simplicity needed to effectively scale, secure and manage the breakup of monolithic architectures into microservices by mediating between the apps (users) and its composite services.

The proxy is the app, for all intents and purposes, because it is the only public interface seen by the app whether that's a native mobile or browser-based app. The proxy is able to provide visibility and security as well as performance-related services on behalf of the "app" because it effectively becomes the app itself. It provides the app routing functionality required to ensure a request to "login" goes to the "login service" while a request to "checkout" goes to the "checkout service" while mediating with the client to ensure performance and security requirements are met.

The (local) service proxy, on the other hand, ensures scale at the service level while providing a service-specific view of performance and capacity. When combined with that information from other services, along with the overall "app" capacity and status at the app proxy level, fine-grained policies can be coupled with real-time monitoring to adjust capacity across the services as well as the app.

Now, you could posit that a "real" app could do these things and you'd be right; it could. The question is what else that app might be doing that can't be duplicated by the app proxy (particularly if that app proxy is imbued with the right programmability)? Because there's going to be an app proxy in front of the app either way; scale and security are still necessary, regardless. So you can have both the app proxy and the app (probably many instances of it) or you very well might consider ditching the "app" and just using the proxy to do it instead*.

It doesn't make sense to complexify the architecture (and introduce additional points of failure and costs to scale) if the app proxy is smart enough to do what you need it to do.

The proxy can certainly be the app. And you never know, it might actually be better at being the app than an app might be itself.

* Assuming the programmatic capabilities exist in the app proxy in question to eliminate the app itself.

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.