Accelerating API Development With OpenAPI and Serverless

Editor's Notes

• #6: 30% of world’s companies are trying to build a digital ecosystem Platforms account for a majority of the internet’s revenue APIs are the centerfold to Platform and API Economy APIs driving strategic business goals with unique business models
• #10: Too many interdependencies Time consuming to add new features or fix bugs Decrease go-to-market
• #14: API-first development will allow parallel development by all teams without the need to wait for changes to be released by one team or another. In the picture above, we can see the first the APIs that are created are mocks. Second, both back-end, front-end, and test teams are starting to work with the mocked APIs. Once the API is ready, all teams can switch to the production or staging API. This saves a lot of development time.
• #15: The definition of your problem space has a big impact on how you think about solving your problem. One way to help ensure you’re always building platform capabilities and not just point solutions is to clearly define the capabilities that compose your business. These become your problem spaces. Business capabilities represent the core, reusable building blocks that your business needs to support the business processes required to function. By defining your business capability taxonomy, you establish a shared language that can be used by all domains to describe the logical relationships in any given process. This serves as a stable, business-driven (not technology-driven) context in which to discuss solutions that, hopefully, remains relatively consistent over time. Is also provides a critical link between how the Business thinks about its investments and how Technology leverages them.
• #20: API-first development will allow parallel development by all teams without the need to wait for changes to be released by one team or another. In the picture above, we can see the first the APIs that are created are mocks. Second, both back-end, front-end, and test teams are starting to work with the mocked APIs. Once the API is ready, all teams can switch to the production or staging API. This saves a lot of development time.
• #21: In traditional software development, the software engineer had to be acutely aware of the concept of a server. Servers are where their software runs. Servers communicate with each other. Servers have IP addresses which need to be discovered. Servers go down which must to be accounted for. Servers have local state that is not visible to other servers. Many facets of software development revolved around the first class concept of a server. Developers write code that implements business logic. Durable state needs to be externalized, local storage mechanisms are for optimization only. Business logic is addressable, not individual servers. https://auth0.com/blog/what-is-serverless/
• #23: Serverless Computing allows me to do what I enjoy, which is write code, without having to provision and/or configure servers. Using the AWS Serverless Platform means that all the heavy lifting of server management is handled by AWS, allowing you to focus on building your application. Serverless can also mean applications where some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a 3rd party. https://aws.amazon.com/blogs/aws/build-your-first-serverless-application/
• #25: Let’s think about a traditional 3-tier client-oriented system with server-side logic. A good example is the petstore example. Where a user can search for pets in an online store and make a purchase Traditionally the architecture will look something like this, with HTML/JS on the front end, and Java implemented on the server. With this architecture the client can be relatively unintelligent, with much of the logic in the system - authentication, page navigation, searching, transactions - implemented by the server application. If we use serverless fucntions instead, then we can “outsource” all of the server framework development to third party vendors, and our only focus would be the server logic. It gives us flexibility in the client to use the various responses given by these functions and add in their own logic to it.
• #30: The definition of your problem space has a big impact on how you think about solving your problem. One way to help ensure you’re always building platform capabilities and not just point solutions is to clearly define the capabilities that compose your business. These become your problem spaces. Business capabilities represent the core, reusable building blocks that your business needs to support the business processes required to function. By defining your business capability taxonomy, you establish a shared language that can be used by all domains to describe the logical relationships in any given process. This serves as a stable, business-driven (not technology-driven) context in which to discuss solutions that, hopefully, remains relatively consistent over time. Is also provides a critical link between how the Business thinks about its investments and how Technology leverages them.
• #40: This piece of infrastructure may be the most important. Given the scale of a large organization, you really need a central place to consolidate all APIs, all documentation, the engagement process, and the overall program status and progress. This ends up becoming the internal developer portal and it’s critical to communicate with and coordinate the actions of the organization. This investment hasn’t been trivial, but it’s been absolutely essential to operationalize the goals of the program.