Driven by the power of the Cloud, the software development process – and development lifecycles – is transforming. Downtime is becoming a thing of the past with highly available architectures and immutable infrastructure. The scale of utilization is increasing as well. We see a large number of workloads being migrated to the Cloud, and, with a few notable exceptions, all new development is being sent to the Cloud.
New Methods Create New Challenges
Generally speaking, the new approach to software development is boon both to developers and business stakeholders; however, there are some interesting new challenges in three areas: (1) Embedding security in the development process, (2) properly leveraging and managing microservices, and (3) managing the APIs that govern the new approach to software.
- Security – As we start using the Cloud and utilizing open source packages from all over the world, the biggest concern becomes the security, validation, and scanning of code at scale. Fortunately, there are more and more tools to ensure that secure code is getting deployed from the very beginning of the software development lifecycle. Vulnerabilities can be detected and prevented from being pulled into your artifacts.
- Microservices – are becoming the new norm for green field and modernization projects. Microservices enable developers to de-couple the application by building small components that take on specific functions. This reduces dependency between the components. However, with more, smaller components that are managed separately, we need to ensure that we manage them in a standard way across the organization. This includes the security policies and protocols that are used for communication between systems.
- APIs – An API is a set of functions that allows the sharing data between independently run applications. Over the past 24 months, more enterprises have begun to modernize their applications by adopting an API (Application Programming Interface) first strategy. This represents a major move away from traditional SOAP-based APIs to RESTFul APIs. Companies can quickly end up with hundreds or thousands of APIs embedded in their applications. These APIs manage new microservices, application security, and the exchange of data, so knowing how to manage them effectively is essential in the world of modern software development.
Introducing Google Apigee – A Revolution in API Management
In 2016, Google acquired Apigee, a powerful API management platform, for $625 million and views it as critical to the success of its Cloud offerings. Apigee is offered as an API Gateway service in the Google Cloud offering and as a standalone product. Apigee allows you to manage your APIs or services in a very clean and streamlined way. Apigee offers both SaaS and Private Cloud options. After creating your service, the next task is to ensure the secure exposure of that service. Apigee allows you to do that in a very well architected fashion.
There are 2 key components to Apigee:
- Edge Mangement UI
- Developer Portal
Edge Management UI
After developing your service on-premise or in the Cloud, you create an API proxy in the Apigee Edge Management UI or as a streamlined API Pipeline which allows you to treat your API development as part of your application development. Apigee provides a lot of tools that you can use to develop your APIs, including Open API to Apigee, which essentially converts an Open API spec to a deployable proxy bundle for Apigee. This doesn’t just help streamline your processes; it also helps create an enterprise strategy of deploying, documenting, and securing all APIs being hosted on Apigee. Some of their most helpful tools are apigee tool, bundle-linter, openapi2apigee, apickli, apistudio.io, and the apigee-maven-deployment-plugin.
The API proxy in Apigee points to your service endpoint (Target Endpoint). Your service is assigned a New Apigee url that can be used to interact with your service. Going forward, you only use the Apigee URL. How you accomplish this depends on how and where you have your services deployed.
Once proxy is created, you have the ability to apply a lot of very essential out of the box security and analytics policies to your service. There are a lot of options to list, but here is the URL to see:
https://docs.apigee.com/api-platform/reference/policies/reference-overview-policy.
This not only allows your security team to have visibility, but also gives a whole suite of information for business folks to determine how the API program is performing.
Developer Portal
The developer portal is basically a place to advertise your APIs and gain or give access. The Apigee Dev Portal is a Drupal based web application that can be customized completely by the customer. A lot of good examples are available, but we always recommend Payeezy:
https://developer.payeezy.com/
The goal is to list all information related to your APIs. This helps the consuming developer to request access and integrate with your API by following the information provided as part of your API spec. All APIs should be treated as external. This allows you to standardize processes across the board no matter what kind of API you are exposing.
In Apigee, you can create API Products that are basically a group of APIs organized into a logical group. This allows you to give access to either:
- Multiple APIs that can either be supported by a specific team
- The services in that product can provide a full set of functionality for example all APIs to look up different inventories.
When a developer requests access in the Developer Portal, they request access to Products, not individual APIs. Products allow you to create non-vetted and vetted APIs, which essentially have different requirements for the consuming applications. This is helpful if you have APIs exposing PII or other confidential data, that should not be accessible unless mandatory.
Security – Apigee has a whole OAuth module built into the platform, which allows you to secure your APIs using OAuth 2.0 which is becoming the industry standard. The developer portal has a streamlined way of assigning OAuth client credentials and validating them. You can also integrate this with your own OAuth identity provider, if required.
An Apigee operations team can create Shared Flows in Apigee, which allow us to create a solid security policy once and then have all APIs call that as part of their transaction flow. In addition, the same Shared Flows can be applied on the environment level to create a higher level of governance posture. The worry of external security and authentication/authorization is taken away from the developer so they can focus on functionality. It also has support for JWT and 2 Way SSL.
Some Closing Notes
As shown in the diagram and the descriptions above, you can see that Apigee provides you with a rigorous, but usable, method for easily managing, securing, and exposing your APIs. There is a slight disconnect between the SaaS model and the private cloud model. New features make it to the SaaS model more frequently, while the private cloud version eventually catches up. Considering the functionality of the platform and the scale of API requests it can efficiently manage, I can understand the complications with trying to keep up with 2 different versions at this scale.
Apigee has a huge community blog where a lot of the issues get sorted out:
https://community.apigee.com/index.html.
To get started quickly and see the available use cases, please take a look at the Apigee Samples GitHub Repo:
https://github.com/apigee/api-platform-samples