As the shift from the traditional world of monolithic enterprise applications accelerates, a host of new problems are arriving.
And one of them could be hiding serious issues for anyone considering making the shift: many of the cloud services we're using as core elements of our business infrastructures weren't initially designed to be components.
That's a significant problem for your next application.
You might be being presented with a RESTful API, but are you getting the right service level for your application? A connection from a core application needs to be treated differently from one build to handle departmental needs. While this isn't an issue with services that have been built to be what's becoming known as "functional PaaS", it's still something that you need to control - if not for performance purposes, then certainly for managing billing.
Sadly too many applications currently rely on people expensing their API access. That's all very well while code is under development, but what happens when it's in production and that personal API key suddenly gets overwhelmed by expensive requests? And what happens when that developer leaves the company and pulls their keys without considering what they're being used for?
With Google making a push for the enterprise cloud market under Diane Greene, its purchase of Apigee makes a lot of sense. With tools to control and manage API use across corporate boundaries (managing both API publishing and consumption) it's a good fit for a company aiming to improve corporate access to its many APIs. Microsoft bought a similar company a year or so ago, integrating it into its Azure offerings.
But that aspect of API management is only part of the story. We also need a better way of authenticating users against API services, with the aim of getting rid of those API keys once and for all. A key that's embedded in code isn't an identity token that can help control access and billing, it's just a one-way authenticator that opens up unlimited access to a remote service.
Okta is probably best known for its cloud single-sign on service, which has evolved to become an effective identity manager and directory service. At its recent Oktane event it announced a new service which should help to fill one of the API management gaps. Its API Access Management tooling will allow IT departments to take their existing identity service and use it as the foundation of API access policies, using OAuth 2.0 to manage connections to APIs and to API management solutions, like Apigee and MuleSoft.
It's an approach that moves away from the API key (and means you're less likely to accidentaly leave a key in a Github repository). By tying access to user identity you're able to manage who gets access and how, bringing in contextual security models as well. If you've built an app that should only be used inside a corporate network, then you can use the user context to ensure that they can only use the application when on a corporate IP address and logged into their user account.
It also allows you to manage access rules without having to use many different cloud control panels. Instead the same policies you're using to control access to SaaS systems and local applications can be used to control API access. Once you log into an app, your account privileges are used as the basis for access to APIs, hiding services you can't use, and throttling access where necessary.
Another set of controls comes from another tool, Zylo, which lets you monitor API usage and tie it to your contracts, allowing you to not just manage deployments and licenses, but also keep on top of billing cycles. With cloud services moving spend from CapEx to OpEx, knowing what you're spending and when, allowing you to manage budgets more effectively, as well as ensuring that departments pay their share of cloud service costs.
It's all adding up to a more mature cloud, one that's striding away from its consumer underpinnings and providing the features enterprises are looking for. Of course, like much of the cloud, putting that new control plane in place requires working with more than one tool - but as the Apigee acquisition shows, the big cloud providers are now working to bring this tooling into their platforms.
Enterprises spend billions of dollars a year on IT services, and the cloud is still only a fraction of that spend. If it's to capture the rest, it needs to build on these trends and deliver the control that enterprises need if they're going to make the cloud and cloud services as much part of their infrastructure as the servers in their datacenters.