The increased demand for software forced companies to look for new ways to accelerate their application building process.
It is no surprise that with the sudden arrival of the pandemic, most aspects of our daily lives shifted online. While companies managed to brush up on cybersecurity and adopt antivirus solutions, the growing use of online services put extreme pressure on application development teams. However, our guest today explains that with the help of APIs, most development issues can be alleviated.
To discuss how APIs enhance the development process, we caught up with Rory Blundell, the CEO of Gravitee – a company helping navigate the modern API challenges.
How did the idea of Gravitee originate? What has the journey been like since your launch in 2016?
Gravitee’s focus is on the ability to manage synchronous and asynchronous API-based communications securely. We started in 2016 in Lille in northern France and have grown rapidly with a real focus on ease of use and security. Gravitee is very well placed to be able to take the new generation by storm and that's what we're all about.
At that particular point in time, we had about 15 customers and now we've got over 100 worldwide. We've not lost a customer in the last two years and have grown phenomenally in a very short period of time – Gravitee now has over 100 full-time members of staff across the US, UK, France, Poland, Sweden, and Germany, to name a few. I think that has been driven by a focus on being a leader for this third generation of API with streaming and traditional APIs all in one platform securely. From revenue to staff and operating countries, our business has fundamentally grown and evolved in the last two years.
What makes Gravitee unique?
The API market, as a whole, was formed around 2000 to 2005. That first generation of API platforms solved a business pain – the cloud was coming. The first generation of integration and API vendors created a layer of abstraction that enabled people to realize the potential of the cloud.
That led to a rise in a second generation – the microservices generation. My belief is that we are now entering a third generation that is no longer about an architectural principle. It's about the data that resides within it. This is where Gravitee is different, we know that it’s no longer just about API's traditional request-response, but streaming in real-time, more accurately, and with more data.
The way we communicate has changed and is driven by consumer demand for more accurate and more real-time data. Yet, organizations still have a lot of more traditional request-response data sources. How do they build, manage, monitor, secure, expose and enable consumption of the different velocities of this data? At the same time as this, you have increasing challenges in the regulatory environment and around information security. Gravitee is uniquely addressing these modern API challenges, which is something that no other organization in this space is addressing.
We can learn as much from customers as they can from us and that they are at the heart of everything we do. The quality of service that we provide is accompanied by a more reasonable price point as well, which is a huge differentiator.
It is evident that open source is an important part of Gravitee. Would you like to share more about your vision?
I remember one of the things that got me into Gravitee in the first place was how open-source it actually was. When I got involved in Gravitee I was just looking for API gateways on GitHub, and what amazed me when I first installed it and started using it was that it was by far the richest open source platform available.
So if I was to download and install some of our competitors' solutions, you're looking at a blank screen or command line, so it really isn't very intuitive. What's amazing from a Gravitee perspective is how much we put into open source. I would argue that probably 80-85% of our code base is open source. We’re very committed from an open-source perspective because our belief is that you reduce barriers to entry and get people using the software as much as possible.
That's the foundation for building a sustainable business model moving forward. In terms of sharing more about the vision moving forward, from an open-source perspective, our position doesn't change, although we will add more features and will try to rebalance a little bit. From an open-source Enterprise Edition, our fundamentals will always stay the same.
We will remain an open core business model and there may be some additional features, but we will never take away features from the community and put them into the enterprise. For example, they will only ever go in one direction, which is enterprise open source. That's a key part from our perspective.
How do you think the recent global events affected the way people approach cybersecurity?
I think there isn't one particular event but I sense a gradual ramping up of people's perception levels about cybersecurity in the last five to seven years.
In particular, one of the markets that is accelerating quite heavily is the API security market. And we know of people, specifically in relation to API security, that are ensuring that their APIs are very full, not full tolerance so much but secure. People’s behaviors are changing, you can see it, and governments are pushing more money into security, not just physical but cyber as well. It's very normal that things start to trickle into the private sector and vice versa and start to work quite symbiotically, so it's not unsurprising that we are seeing genuine changes in behavior to do with companies' approaches and cybersecurity.
In your opinion, why do certain companies hesitate to implement open source solutions?
I personally don't believe this is the case anymore, if you think back to about 10-15 years ago when the Apache Software Foundation wasn't as large as it is now with its well-known projects. I think it's really fundamentally changed people's perceptions on when to go open source or whether they're willing to go open source or not.
I also think as software development has evolved, the understanding that people have from software because software development like data is the new medium for transacting, basically, software developers are a rich commodity. And the reality is that software developers are much more understanding and au fait with the concept that open source libraries, however big or small, are used everywhere. I personally don't believe that there is a great hesitancy now, there is some but I definitely think it's fundamentally different from what it was previously.
Why do I think some of them hesitate on it? I think it's an old mindset. If you look at the Gravitee software development lifecycle, it's a very robust lifecycle in that every single bit of code that's checked in has to be reviewed internally, you then use tools like snip for example, and we very much follow this line principle for everything. The very first line of code or any thought even from the ideation phase is very much focused on security and best practice. So, from my perspective, I don't think there is such a challenge anymore.
What are the best practices companies should follow when developing, and, when launching applications?
Organizations nowadays are struggling to meet the demands of their customers. Customers' behavior has now changed and this was especially accelerated by the impact of COVID.
All this has created the need for organizations to have an online presence to deliver those same services. This created the need to innovate faster and also the need to compose data, processes, and/or applications to avoid having to reinvent the wheel every time a new solution needs to be built.
The de-facto standard in building applications as composable building blocks is by leveraging APIs exposed by existing applications. In building new applications the following principles should be followed:
- Reuse existing APIs whenever possible – this will reduce the delivery time and time to market by leveraging the work that had already been done which will result in a cost reduction in operating costs, bugs, and maintenance.
- Treat APIs as first-class citizens rather than an afterthought. Organizations should abandon the approach of considering each application as a mono-use artifact to only have to add APIs on top later. Applications should be built with API in mind and these APIs should be designed using a specification language that will help deliver a great DX (Developer Experience).
- Adopt a Design-First approach – starting the development of an API by designing its interface (the “I” in API) brings many benefits.
- Adopt security by design – security should be top of mind when designing an API.
- Adopt an API Management strategy for your APIs.
Why can managing APIs often be a complicated task?
Managing an API typically involves:
- Contract design, as described above
- API implementation, testing, and deployment
- Security, SLA, Quality of Service, traffic shaping, etc.
- Monitoring and Alerting
- Publishing and consumption
Managing an API is hard and organizations should adopt an API management solution that already solves the problem of making API management easier. This way organizations can focus on the problems that are at the core of their business without wasting time on tasks that are better left to organizations like Gravitee that have already solved the API management problem.
What does the future hold for Gravitee?
The aim is to lead this next generation of API. Gravitee can alleviate the challenge that businesses face when they have a myriad of data types moving at different velocities. There is no one consistent way to build, manage, monitor, secure, expose and consume all of this data, and I believe that Gravitee has the platform and the team to be that leader in this next generation of API.