Happy Daylight Savings Week! As we adjust our clocks and our sleep schedules, spring forward with us as we dive into what we shipped in February.
Modern Security for Modern Applications
Curabitur at mauris magna. Duis sollicitudin odio in arcu ornare, quis pulvinar eros facilisis. Nunc a sodales ex. Nam sagittis diam maximus lorem aliquam, a tincidunt ante rutrum. In facilisis risus tellus, mollis viverra massa fringilla et. Nunc porta risus mauris, non egestas libero vulputate a. Fusce consectetur convallis orci eu consectetur.
Mauris vestibulum orci sit amet turpis finibus
Curabitur at mauris magna. Duis sollicitudin odio in arcu ornare, quis pulvinar eros facilisis. Nunc a sodales ex. Nam sagittis diam maximus lorem aliquam, a tincidunt ante rutrum. In facilisis risus tellus, mollis viverra massa fringilla et. Nunc porta risus mauris, non egestas libero vulputate a. Fusce consectetur convallis orci eu consectetur. Donec convallis sollicitudin egestas. Vestibulum nec augue non arcu faucibus rhoncus.
Nulla ac ligula commodo, volutpat diam nec, tempor mauris.
Vestibulum malesuada, augue egestas varius scelerisque, tellus massa ultricies nibh, in malesuada est diam id lacus. Fusce vel imperdiet enim, nec porttitor felis. In aliquam quam a erat placerat sodales. Class aptent taciti sociosqu ad litora torquent per conubia nostra.
Quisque imperdiet, neque accumsan eleifend porttitor
In eu finibus eros. Donec in tortor tincidunt, laoreet eros a, ornare lorem. Nulla ac ligula commodo, volutpat diam nec, tempor mauris. Nunc faucibus mi dolor, sit amet fermentum est egestas sed. In sodales malesuada risus id imperdiet. Nunc hendrerit ultrices volutpat. Mauris tincidunt volutpat odio, vel luctus risus imperdiet a.
New keyboard shortcuts for search in Metronome UI
Nulla facilisi. Curabitur dolor diam, faucibus vel ipsum ut, varius rutrum elit. Nunc at odio neque. Fusce vulputate porta mauris. Nam eu sem efficitur leo tincidunt hendrerit. Aenean porttitor metus et metus mollis tristique. Phasellus at cursus quam. Etiam sodales mi ac suscipit dapibus. Aliquam justo dui, ullamcorper efficitur orci a, lobortis auctor lacus. Suspendisse accumsan dui in vulputate finibus. Mauris vel porttitor ligula. Aliquam ut mollis augue. Aenean posuere diam a consequat scelerisque. Etiam molestie arcu gravida turpis pharetra elementum. Ut venenatis eleifend diam ut blandit.
Being API-first can unlock explosive growth for software start-ups and offer leverage - in terms of quality of development and a better user experience. For example, Etsy switched to an API-first approach after facing the common challenge of implementing their logic twice.
But what does it really mean? Much like the (overused) term serverless computing confuses some people in the cloud industry, being API-first has a nuanced meaning. I wanted to share some recent conversations with developers, engineers and CTOs building the next great SaaS companies, and how they described this term to me.
First, do APIs matter?
APIs, while ubiquitous in our daily consumption, still feel nebulous and amorphous. The temptation to use a popular web framework, a Postgres/MySQL database and a hosting provider feels like the path of least resistance. But the world's leading businesses like Twilio or Algolia, have launched as API-first businesses. There are several reasons to being API-first:
Earlier validation: Getting early feedback on your design allows teams to adapt to any new inputs, and reduces the lifetime cost of the project.
Clear abstraction layer: showing only the necessary details to users hides internal complexity. This allows others to ramp up more quickly when implementing the new service.
Faster growth: building out the API design early on takes future functionality into account, laying the groundwork for expansion, and accommodates the ability to quickly scale to other apps, devices, and platforms.
Cohesion and avoiding duplication of efforts : Best described via the image below - where all clients (1st and 3rd party) converge to a common set of functionality backed by APIs. This improves speed of development and creates infrastructure efficiencies.
Above I have described functional and technical benefits of an API-first approach. But over the years, my view has converged to a single core idea: APIs can insert themselves in any workflow - they create for leverage and customization in ways UI components and workflows can’t.
This means functionality (like stripe payments) can be inserted into domain specific clients without the need for retooling and the redesigning of UIs. This has sparked an incredible amount of innovation, and API-first companies (like Stripe , AWS, Plaid etc) have enjoyed breakthrough success having others build on top of them (vs. have their UI integrated with others). But going from "we have APIs" to "we are an API company" is a shift in the mechanics of software development and business goals.
You can be API-first if your business commercializes APIs and provides APIs as a product. But API-first also describes an approach for API developers to define and design APIs schema before development. After my conversations with peers, my view is that being API-first is a mindset. Ask yourself: "will we deliver the most value for our customers by building dependable, robust and secure APIs".
This doesn't preclude you from writing a quick prototype, where API paths, resource definitions, operations are layered later on. The latter is incredibly important if you want to foster developer-led growth. But separating mechanics from principles, helps in building quickly without losing sight of the business goals.
What does API first look like in modern organizations?
Twilio virtualized traditional telecommunications infrastructure allowing developers to replicate any communications experience using APIs. The business recently announced Twilio Build, a partner program designed with an API-first approach.
Some organizations adopt an API-first approach to optimize their total development time. For example, Etsy switched to an API-first approach after facing the common challenge of implementing their logic twice. Besides increasing extensibility for new devices and features, Etsy’s optimized their platform’s performance by enabling concurrent API calls previously limited by their PHP code base.
Another example of an API-first company is Netflix. Accounting for a large percent of total internet traffic, Netflix re-configured their API architecture to improve performance and enable UI engineering teams within Netflix to optimize client applications for specific devices. The end result is a fault-tolerant, performant platform that puts control in the hands of those who know their target applications the best.
To create leverage, APIs should be treated as a long lever over a fulcrum. If you look at the Etsy example above, all client (user, device, etc.) interactions converged to a single API surface area. Users make API calls via the UI, and other client/automation scenarios route to the same surface area because all business logic is compressed neatly behind API calls.
Today, engineering teams have separate groups for building new functionality and scaling their APIs. While dedicating resources shows commitment to an API-first approach, it can result in losing the leverage and cohesion that APIs were meant to create in the first place.
For example, APIs tend to have separate administrative experiences. API calls tend to get tracked and logged separately from calls initiated by a user via a UI, which can result in losing tracing fidelity when debugging issues. Access rules for API clients are defined separately, which means that developers have to build and operate permissions and security controls in two different places, etc.
Some of the workflows that apply to API management will be different, but the overall experience should be cohesive. Users and administrators should not be forced to hop between tools to get a particular administrative job done in your application. They should be able to on-board, secure and audit the application experience in a unified way.
If APIs are treated as the source of truth for functionality, then you can use an API definition to create leverage and cohesion. The API spec can be used to generate server stubs and save development time, or scale APIs via popular API Gateways that improve the user experience. And you can even leverage an API definition to build a great user management and security experience for your app.
For instance, OpenAPI is an interface definition language for describing, producing, consuming and visualizing RESTful APIs. The spec captures resources, paths and operations supported by an application. And Katanemo helps developers build slick user management, security and auditing capabilities for their apps by submitting their OpenAPI (or GraphQL) spec to us.
If you don’t know what Katanemo is - it unifies user, machine and enterprise identity with a fine-grained security and sharing service so that developers can focus on their core competency. We help developers unlock adoption via a single user sign-up, and effortlessly scale usage via thousands of enterprise users using Single sign on (SSO) features. We enable developers to offer automation via API keys, and help them build critical sharing and security features that leverage their API schema.
Incidentally Katanemo itself is API-first, and uses Katanemo to power its multi-modal identity, security and sharing experience. You can read more about how we solved this circular dependency problem via APIs.
While a collective measure of global API consumption is hard to come by, consider the following stats.
Allied Market Research reports that, “The global microservices architecture market size was valued at $2,073 million in 2018, and is projected to reach $8,073 million by 2026, registering a CAGR of 18.6% from 2019 to 2026.”
The growth is a sure indicator that we are in an API-First era, where well-functioning API ecosystems are crucial for businesses to stay competitive. For a long time, Jeff Bezos has held that increasing your rate of experimentation is necessary for successful invention. APIs enable that fully.
APIs drive operational and business leverage, and they should serve as the foundation for your application experience (user, administrative, security or otherwise).
Build modern software companies without the infrastructure tax