Sign up to save your podcasts
Or
Share Episode 41: Apollo GraphQL, revolutionizing how developers write modern applications, with Geoff Schmidt, CEO and Co-Founder
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Episode 41: Apollo GraphQL, revolutionizing how developers write modern applications, with Geoff Schmidt, CEO and Co-Founder
Geoff Schmidt, CEO and Co-Founder of Apollo GraphQL, says you don’t get to pick your business model, you get to pick your problem. As part of the team who authored one of the most popular monolithic JavaScript rapid application development frameworks, MeteorJS, Geoff describes how they applied their experience to address an even bigger challenge–how to build more flexible backend data services.
Intro
Michael Schwartz: Welcome back, Underdogs. I’m your host, Mike Schwartz, and this is ep isode 41, with Geoff Schmidt, Co-founder and CEO of Apollo GraphQL. Geoff and his team have a gift for looking at the same problems we’re all looking at, and coming up with inspired solutions. After developing Meteor JS in 2011, they developed the Apollo GraphQL platform, which has coalesced and expanded its community in just a few years.
Geoff has some tactical advice on how to engage
with your community to build an amazing business. Apology in advance if there
are a few audio blips on this episode.
If you like the podcast, please help us get the word out. Like it on iTunes, or even tweet at a link on opensourceunderdogs.com. Our handle is @fosspodcast. Enough shameless self-promotion, let’s get on with the interview.
Thank you so much for joining the podcast today.
Geoff Schmidt: Of course, it’s a real pleasure.
What Is GraphQL?
Michael Schwartz: What is GraphQL, and how does it relate to the Apollo GraphQL platform?
Geoff Schmidt: GraphQL is kind of like a query language for the cloud. We’re in an interesting situation right now, where, if you go back 5 or 10 years, the way we built apps was really different. You might have a web server and a web server might connect to a database or two. And then, on the front end, you might have a web browser, maybe even a mobile app.
But now, we’re in this situation that is a lot
more complicated, where people are expecting more and more from applications. The
applications have a lot more of a richer interactive experience, they do a lot
more, they’re also available on more platforms, and at the same time the
services in the cloud that back those apps got a lot more complicated too. It’s
not just a web server and application server, it’s a whole bunch of different
micro-services typically.
And so, you’ve got this problem of, how do you
connect all of those devices, all those apps and all that sophisticated
functionality to all those services that exist in the cloud. And the old way of
doing this was with REST APIs. REST APIs require that you write a bunch of
custom code basically for every screen in your app, probably a new REST
endpoint for every use case.
And with GraphQL, it’s a flexible query language,
so an app developer can ask for any combination of data that they need out of
the cloud, and you don’t have to write custom code anymore, like you would with
a REST API.
So, one way of looking at it, it’s a better way for app developers to be able to query all the day that exist in the cloud, it’s a much better experience for the developer. Another way of looking at it is, it’s a way that an organization can build a connected map of all their data and services in the cloud, so you can have one central organizational source of truth of all those resources.
And I think another way to look at it is, it’s almost like an abstraction layer for the cloud. It’s a way that you can, even as you are writing your applications, even as you are building your micro-services, you can keep like one consistent stable map, so that really gives you the ability to write a lot more apps, build a lot more cloud services, and evolve your all infrastructure really, in a flexible and more principled way, now that every app has an API inside of it.
Origins
Michael Schwartz: Can you walk us back to 2011. Meteor development is founded – where were you then, and how did you develop that into Apollo GraphQL?
Geoff Schmidt: Sure. This whole journey started for us back in 2011, we were in one of the early Y Combinator batches back in summer 2011, and I was meeting a couple friends, and we had a lot of different ideas, but what we wanted to do is, when we got into Y Combinator, we discovered that all of the people in our Y Combinator batch were really struggling to solve the problems of modern app development.
2011 was kind of a tipping point, when the world
went free on rails with PHP as enough, to “Wait a second, now people have
bigger expectations about the user experience, where they were trying to
deliver that user experience.”
So, what we decided to do is, me and my co-founders, Matt Debergalis and Nick Martin, we’d work on a variety of other projects together, each has been trying to build a different combination of apps, or open-source projects, or SaaS products, and we thought, “Can we take everything that we know about building modern applications and put it into a reusable framework?” That would help people build apps faster.
That gave birth to Meteor JS, which we launched in early 2012. And it grew over the next couple of years to become one of the top 10 most startup projects on GitHub.
When we launched Meteor 1.0 there were local media
meetups, I think 134 cities around the world on the same day. So, we had big
success with this monolithic JavaScript open-source app development framework. And
we were able to build a profitable business on top of Meteor JS with Galaxy,
which was a hosting platform for Meteor.
But what we started to realize, as we got toward
the end of 2015, there was a bigger opportunity, because we were finding that
people wanted to connect Meteor, not just a MongoDB – which was the database that
came in the box with Meteor – but they wanted to connect it to all sorts of
different sources of data and services in the cloud.
We also found that people wanted to build app
experiences that were not just JavaScript in the web browser, but across any
number of different mobile platforms, and increasingly, like all kinds of new
stuff, these IoT platforms, all these things were happening.
And we really said, “If we could take the technology
inside Meteor or the ideas, architectural ideas inside Meteor, and put that in
a form where you can use it not just for new applications like Meteor for any
app, and you can connect it to any source of data in the cloud, not just a
particular database, and you can push into many platforms, not like just one
front-end, written in JavaScript, then, it would have an even broader
applicability.
The other thing we saw was that Enterprises were
starting to adopt Meteor JS, and we were getting much more familiar with the
needs that you see when you are building highly-scaled applications of
Enterprises, not to scale in terms of how far the technology scales, but scale
in terms of how you have larger code bases, larger teams. And so, that led to
us starting to research like what would Meteor 2.0 would look like, what would
the component to that be. We’d also seen the rise of react.
And we’d seen that something like react, that’s
incrementally adoptable, where instead of having to build a new application,
you can add it to an existing application, quickly get up and run it, and
quickly get some proof points – we saw how powerful that was for growth. So, we
thought, “Can we build a new data layer for Meteor that takes everything we learn
from the whole experience with Meteor that is a very powerful open-source
project?”
Everything we learned from Enterprise customers,
everything we learned about the proliferation of back-end services in the cloud
and new front-end that people wanted to use, and put it in an incrementally
adoptable form. And that’s the end of 2015 I guess.
And that’s when we heard about GraphQL. GraphQL
was just what we needed to work on this new project, which is what we were calling
the Apollo project, because Meteor has been so tied to MongoDB, whereas
GraphQL, this whole idea is, it’s this database agnostic abstraction that lets
you talk to any number of different databases or cloud services.
We set it to take some of the core ideas or learnings from Meteor, make it speak GraphQL as a query language, build something that is very easy for people to drop into existing applications. And then, we started launching the first Apollo open-source component in early 2016, and it’s been really amazing couple of years as more and more people adopted this technology. I think it’s really exceeded any expectation we had for it back in 2016.
Sales
Michael Schwartz: Can you talk a little bit about how your sales processes have evolved, because I would imagine initially there was a lot of organic inbound Enterprises saying, “Okay, we want to use this software, but over time, how has that changed and adapted to the demand?”
Geoff Schmidt: I think we have seen a trajectory that’s pretty typical in the sense, yeah, to your point. Some of our first customers were people that were already very sophisticated users, very sophisticated early adopters, who were using Apollo at scale in the Enterprise, as well as people maybe who were small, midsized businesses but had a strong vision for what they wanted to do, and they wanted to get a technology partner for their vision.
Some of those first customers, there were
various things that we helped them with, but in a lot of cases, it was the
relationship with us, maybe some code development on the open source, us carrying
the pager for their assistance maybe.
There’s a couple of different ways those things were
structured, but what happened was, more and more of our businesses shifted
toward the additional tools and services that we were able to provide around
the core Apollo Client, Apollo Server open-source offering.
We have a product called Apollo Graph Manager.
Graph Manager is essentially the control plane for a data graph, so, we have Apollo
Client, Apollo Server. It’s basically the date plane, it’s the stuff that goes
in your data center to answer queries, the stuff that can’t go down, stuff that
handles all of your personal data, all your sensitive business data.
But what we found is both as companies scaled the Graph, they go from just a couple developers to 10 developers, to 100 developers, to 1000 developers. There is a lot of additional management tool that you want. There’s also a bunch of architectural best practices that are really helpful. It’s really helpful to put your Graph schema in a schema server, have a central source of truth for the structure of your Graph, how it is changing over time, build workflows, and processes, and governments around that.
At the same time, one of the best parts of the Graph tool is the tooling that’s possible around it. And that tooling is super valuable very early in the development process as well. And so, the SaaS services we built that are essentially souped-up set of developer tools, and even more so, a control plane for a scaled enterprise data graph.
That’s all packaged up in a SaaS service we call
Graph Manager. More and more of our business now is Graph Manager. And what
we’ve done is, we’ve created both an Enterprise offering around Graph Manager
that comes with the full 24/7/365 SLA for the whole Apollo platform, covering
all the open source, all the SaaS, as well as our support and expertise. As
well as some like in Enterprise Edition of Graph Manager that has features like
single sign-on, some of the things that are Enterprise specific requirements.
As well as having, we go all the way down to a $49
per seat per month offering that anyone can buy online with a credit card
because you want the support through the whole development cycle.
And we also have a freemium offering. If you
just want the developer tools for the earliest stage of development process, you
can use it for free. We’ve really tried to understand what the entire user
journey is from the moment you write the first line of code and start exploring
GraphQL, all the way through to when you have a scaled graph in an Enterprise –
it’s the strategic asset.
We tried to understand how people want to buy and how people want to partner with us at each of those stages. And it’s an ongoing process, but we’re building our packaging around that user journey to try to accommodate each stage in the journey.
Revenue
Streams
Michael Schwartz: What would you say the current breakdown is of SaaS vs. license revenue? Which part of the business is more important today from a revenue perspective?
Geoff Schmidt: I think there’s some open-source companies where the service offering is a bolt-on, like maybe it’s a nice to have. But it’s not really that critical. Or, in some cases, something was included primarily just to drive renewals. That’s not the case for us. We find that the Graph Manager, the SaaS tools are very important to people as they scale, and also are something that people really value early in the process.
I would say that almost every customer is using some form of the SaaS tools. Now, in terms of what’s the breakdown of revenue versus people are purchasing online versus people are purchasing more Enterprise subscriptions, Enterprise subscriptions are a big part of the revenue. Right now, from a customer count point of view, it is more online purchases, but most people are using some form of the Graph Manager, though there are exceptions to that.
How To Align With The JavaScript World?
Michael Schwartz: JavaScript is the largest community. Do you have any insights on how other open-source companies can align with the JavaScript world?
Geoff Schmidt: JavaScript is really about the rise of app developers, and it’s about the rise of accessible app development. It’s one of the easiest languages to learn, and there is a huge amount of demand for more sophisticated websites built in JavaScript. A lot of what drives the rise in the JavaScript is, there’s this whole world of apps that are written on kind of this LAMP stack derivative frameworks that date back to, in some case, the nineties, like PHP, Ruby on Rails, ASP. Net, Spring. Like the LAMP stack approach to building applications.
And what’s going on right now is, a lot of these apps that were written on those frameworks are getting re-platformed onto a more modern app data stack that includes React Apollo, some of these other components are going to be building a modern experience. I think that the way to think about how you align with JavaScript is to think about how you align without movement toward like modern app development. The thing is, most of the time when a company is going through that transition with a re-platforming, it’s part of a larger modernization effort.
They are often evaluating other technologies too,
and they are thinking about, “Hey, is this a time for bringing Kubernetes?” Or,
“Is this a time for bringing a different version of mobile development?” Is
this a time to go to different platforms?” I think like every offering’s going
to be different, you either have an axis with modern app development, or you
don’t. If you do have an axis with modern app development.
I think it’s really important to understand like the JavaScript constituency is going to be one of your biggest users if you can understand really what their pain points are.
It’s very driven by community. I think front-end app developers, by nature, they value design, they value community, there’s a really great community there, they are collaborative and positive, community that is more diverse than Symantec, it’s more accessible than Symantec.
Making an investment in how you meet that
community where it is, understand what the values of that community are, and maybe
build some relationships with the leaders in that community, I think can really
help you reach those app developers.
The other thing that’s important is to
understand that it’s a community that cares a whole lot about user experience,
maybe more so than some other communities. It’s what you do every day is an app
developer, you think about how you deliver great user experience to users. It
tends to be people that value good user experience.
I think those are some of the values of the community that can help you get more mindshare more quickly if you do have a product that is related to modern app development.
Benefits Of Open Source
Michael Schwartz: Has the open-sourcing of the code materially benefited the company?
Pricing
Geoff Schmidt: Absolutely. Apollo would not exist today if we were not open-source. I don’t think there would have been anyone to do this, other than as permissively licensed set of open-source libraries.
Michael Schwartz: You were mentioning pricing before, and actually I think pricing is really hard for Enterprise startups. In your industry, it sounded like you had a logical gating mechanism, like you mentioned number of developers. Do you have any advice – going from 2011 to today – any advice on how do you find the right price and the right gates for your software?
Geoff Schmidt: Well, it was a journey for us to get here. We originally priced based on query volume, so the number of operations that you performed on your graph. And the reason we went that direction is, we thought of it as utility, like AWS. And we thought, “How cool it would be if you had a very predictable, very simple way of understanding, “Hey, here’s what my costs are going to be.” If you told like electricity, or water or cloud computing. And we thought that was a model that everyone was really familiar with, that would feel like a natural way to purchase infrastructure like a data graph platform.
What we learned was that query volume pricing
wasn’t very well aligned, either with how people wanted to buy and budget for
technology in this case. And also that wasn’t very well aligned with the value
that we were providing.
We had customers that were doing maybe billions
of queries a month with a small team, and we had customers that were doing maybe
millions of queries a month with a much larger team, for like maybe an even
more valuable line of business.
Like the business I associate with the query is
so different across maybe a B2C app that is like mostly freemium, versus an
internal line of business application. So, that lack of value alignment, which
kind of manifested it as the platform would get way too expensive, way too
quickly for some people, whereas other people that were driving a lot of revenue
from the product and getting a lot of value were very happy with, they might
only be paying $2 a month.
It manifested as a churn of some of our largest
customers as the query volume pricing just got unaffordable. It manifested as a
lot of people who had to contact sales to better understand the pricing. It
also manifested as longer sales cycles because it meant that we were forcing
people to predict their usage of the Graph far into the future, because if
you’re going to adopt this like core piece of infrastructure, you really want
to have a good way to understand what your costs are going to be.
If you are looking at this thing and you are
thinking, “Man, this is probably going to expand to be all of my app
development and all of my traffic.” And especially if it’s a new technology,
where you don’t necessarily know the estimate, how many queries are going to be
doing, like how many react components might use this, how many queries might
each one do, that’s really scary, and it slows adoption and lengthens the sale
cycle.
So, what we did was, we listened to customers to
understand what’s the most easy and natural way for them to buy what just feels
like a great experience for them. And what we found was, at the early stage of
the journey, especially if you’re doing a self-service purchase online, or if
you are an internal manager that is just buying it for your team, thinking
about it as developer productivity, see pricing is A very natural and easy way
to understand it because it’s proportional to the investment you’re making and
developing your application proportional to your team size.
It’s also pretty easy to predict and plan, and you
could plan it alongside your other cost. And as we get into some of the enterprise
tiers, there’s a platform fee as well, which is based on sort of the overall
intensity of use of the graph, which is a couple of axes.
Query Volume is an axis there, but it’s only one
of several axes that we used to understand, like, “Hey is this an individual
team?” Maybe it’s a whole business unit, maybe it’s a whole much larger company
that’s all family different brands. We found it really startling with an
understanding of how people want to buy and aiming to serve the customer,
rather than saying, “What do we think our users might want?” Or saying, “What’s
the easiest way to plan our business?” was really, I think for us the master
key in fighting the right pricing.
Pricing Process
Michael Schwartz: To get you to your new pricing model – did you appoint somebody who is heading up that task, and who made the final decision around what to charge?
Geoff Schmidt: It was my co-founder who’s also our head of product. It was a process that involved many people in our team, many customer conversations, listening to what we were hearing from the sales team, listening to what we were hearing on the developer relations on open-source side. A lot of conversation inside the team, and ultimately, it’s one of the decisions that is hard to change, that you don’t want to be constantly changing your pricing, at least your pricing axes. At some point, you have to gather information you can, and make a decision to commit to it, and take it from there.
Open Core?
Michael Schwartz: Would you say that you are open core?
Geoff Schmidt: I would describe us as a complementary product model, so we have our open source. And right now, we don’t hold anything back on the open source. Could there be open core Enterprise features in the future? Yeah, maybe. And we’ve heard some requests that it might be a good fit for that model.
But currently, open source is just open source,
but what we offer is a SaaS service on top of that. I think of it as a
complementary product. The way I think about that from a business point of view,
if I think about advice I give open-source entrepreneurs, I think your business
model as an open-source company is not necessarily something you can force. Like,
I don’t think you get to pick your business model, I think it’s more like you
get to pick your problems, like pick what you are building. And then, that will
have a natural business model associated with it.
I think that there are some things that are open
source that are just really hard to monetize. There’s a lot of things that are
100% in a view layer on the front-end, there’s just not a natural way to
monetize that. These things, their ultimate destiny, at least I think for the
foreseeable future, and in a lot of cases, they are just going to be open-source
libraries.
There’s other things that can really naturally
be monetized by selling supportive services from day one. There’s other things,
like get offering in an open-core model.
There’s other things that very naturally can be
monetized by saying, “Hey, I have some open source.”, but any using this open
source, many of them will want the SaaS service. I think Git and GitHub is a
great example of that.
I think you have to start with what the natural
structure of your solution is, and ask, “What are the pieces of this that your
users would like to be commercial?” And, “What are the pieces of this that your
users would like to be open source?”
And follow what really does right for the user in order to find out that right model. I think if you try to go the other way and say, “I’m going to try to force particular business model on this because that’s my strategy.”, I think you’ll end up creating worse experience for the user. And I just think that the world we are in with dev tools and the internet today, there are so many opportunities. I think you’re going to see competition that correctly shapes product, I think it is going to win with the correctly shaped business model.
Is There Amazon GraphQL?
Michael Schwartz: Is there an Amazon GraphQL hosted service similar to what you’re offering?
Geoff Schmidt: Amazon does have a GraphQL offering called App Sync. App Sync is more focused on mobile development, and it’s more focused on getting mobile developers a great way to access all the data and resources they have inside Amazon. It’s a little bit more of a back-end as a service. Maybe that’s not a quite right way to study because it can do so much more inside Amazon.
That’s different from what Apollo is, which is
focused on integrating many different data sources in the cloud as some of you
can incrementally adopt. You can add Apollo to any existing application or
stack, whereas App Sync is designed a little bit more for new application
development typically, so they’re actually complementary.
It makes a lot of sense to say, “Apollo is my
data graph integration layer, and then maybe I could have App Sync with some of
my back-end services. With technology like Apollo Federation, they are good
frameworks for how we can think about federating multiple GraphQL services
together to build one graph.
Some of the details that are still being worked out because a lot of this is a new technology. But, conceptually, I see them as complementary products rather than competitive.
Would Amazon GraphQL Be Good Or Bad?
Michael Schwartz: Let’s just say that Amazon takes the Apollo open-source server and lunches Amazon Apollo server service – would you view that as a positive or a negative?
Geoff Schmidt: I think the more the merrier. I would love to see more people running Apollo server on Amazon. And if Amazon helps them out, that’s great. We’re focused more on how you scale the graph, and that has a lot more to do with workflows, and the control plane, and a schema registry, a bunch of other things that are like really different from a SaaS offering, and really different from Apollo Server and Apollo Client.
I think the more people are building services on top of GraphQL, and the more GraphQL grows, the more people are going to need solutions for managing large GraphQL, like Apollo Graph Manager. But I think it’s a positive for us potentially.
Open Source V. Commercial
Michael Schwartz: Do you ever feel any friction between, when you’re introducing a new tool, and between should this be open source, or should this be commercial? And how do you decide which way to go?
Geoff Schmidt: For us, we have a pretty bright-line. We start with, “Does this naturally exist inside the SaaS offering or does it just naturally exist inside the open source?” And I think that’s been a really reliable benchmark for us.
On some level, that’s just a technological fact,
like where to go, where to live, in our case, because we have a SaaS model
instead of being open core currently, but I think there’s some things that we
learn along the way that I can talk about.
I think one of the core ideas is, companies who
want to own their data graph, this is a very important investment for them. And
they don’t want to feel beholden to an outside vendor, just for the continued
existence of that, and maintenance of that thing.
At the same time, they also want to see strong
vendors with viable business models because they want to know if there’s going
to be somebody there to support them. I think your challenge as a vendor is
helping craft that right relationship with your customer, so they feel comfortable
and secure.
And they trust both of it, you’re not going to be in a position with too much power over them, but at the same time that they trust that you’re going to be around. It’s very rational considerations that customers have when they’re selecting a solution like this. And downstream from that, focus on customer trust, and just really trying to understand what would you want if you were that Enterprise that was purchasing the software, or adopting that solution whether it’s open-source or commercial.
I think that some of the principles we found are
what’s inside owning your graph, controlling your graph, it’s important that
people own the entire data plane, so everything from when the request comes in
all the way through to when it’s answered by your services and the responses stitched
together and sent back down to the client.
You want to feel like you’re in control of the
uptime of that. You want to feel like you’re in control of the security and the
privacy associated with that. You want to feel like if there’s ever an issue,
you can look under the hood, read the code, understand what’s going on, and fix
it without necessarily waiting for round trip from vendor, at the same time, as
you want to have the vendor on a 24/7/365 pager rotation for you.
So, when we think about the features that relate to keeping your system secure, and private, and up, to me those are the things that have to be open source. When you think about the things that relate to how we manage the workflows and processes around it, where maybe it is tolerable for some of those aspects to exist inside of a SaaS platform, and maybe it’s even better. Because you have a supplier that’s constantly keeping that up-to-date data adding new features.
And it’s delivered as a managed service to you. Those are the places where I feel like the SaaS stuff fits really naturally. And so there’s some nuance and complexity there about how we’ve been sharing that. So, for example, one of the things that Graph Manager can do is, it can manage the deployment of your Apollo gateway instances. If you are using Apollo Federation to manage the whole constellation or fleet of these different GraphQL back-end services in a federated architecture.
So, to do that, what we do is we push Graph Manager
push the configuration that those Apollo gateway servers are going to need to pick
up into a highly-available, global distributed CDN.
That way, we are doing the analysis of how is
this going to affect my uptime to have this dependency on this other component.
You can see even if Graph Manager goes down for 30 seconds, it’s not going to affect my ability to scale up and down my servers, because we’ve found a solution like the CDN to ensure really high uptime for our services.
GraphQL Foundation
Michael Schwartz: Last year, you announced the GraphQL foundation, I’m wondering is that self-sustaining, and what role the foundation is playing in the ecosystem?
Geoff Schmidt: The GraphQL foundation, that was put together by us together with Facebook, and the Linux foundation, and a few other great founding partners coming from Facebook, the folks that originally wrote the GraphQL stack and created the GraphQL language.
The foundation is self-sustaining, it is one of
the auspices of the Linux Foundation. The way I see foundations, they are the
keepers of the specification. It’s really important that a technology like
GraphQL that we have a way in industry to evolve, going forward, while
maintaining interoperability.
I think in the early days of GraphQL, there were
a lot of questions about the relationship between GraphQL and Facebook. There’s
a lot of positives there because there’s a proof point about how GraphQL has
powered applications at massive scale at Facebook for years. And I guess people
have a lot of confidence that it’s a good, technological direction.
At the same time, too much control by Facebook that isn’t the developer tools company I think was a little bit of a concern for some folks. And now that we have a foundation that can be the custodian to stack, I think that’s a development that’s given folks a lot of comfort and confidence.
Changes In Enterprise Software Market?
Michael Schwartz: The Enterprise software market has changed a lot in the last 10 to 20 years – can you talk about how you think vendors of open-source software should think about their strategy today?
Geoff Schmidt: I think the key thing to understand first is, to the extent, how you are thinking about how you monetize your open source, who is the buyer, is the buyer going to be an end-user, in which case you probably have more of a bottoms-up motion, where it’s probably a product-led motion, where you’re focusing very much on the user’s first moment experience, and what the value proposition is for that first credit card swipe.
And then maybe after that, thinking about what
are the layers that drive and upsell the Enterprise possibly as the graph
grows, and maybe what starts being used by multiple teams, or whatever your
product is.
There’s another approach that can also work well
I think, where, if the buyer is more naturally maybe a leader inside the
infrastructure team, or maybe another executive where it might make sense to
enter around the 1500- $50,000 price point, where it’s more like a
comprehensive Enterprise subscription offering.
I think the thing to understand is what really is the adoption model of your software inside the customer, and understand is it really driven by end-users that want to purchase easily online, or is it driven more by the need to have a business relationship and a vendor relationship. And I think that ends being, in my point of view, the driver of how you build your go-to-market strategy.
Advice For Open-Source Entrepreneurs
Michael Schwartz: Last question, any advice for new entrepreneurs, like the people who are starting this business around an open-source product, what advice would maybe you give yourself, if you could go back 10 years, or so, 9 years?
Geoff Schmidt: It’s a good question. I guess I would say they’re not the easiest businesses to start but they’re some of the most rewarding. Because you get to hold an incredible community, and you get to touch a lot of people, you get to do it very quickly at internet scale. And I think one of the idea about doing open source right is, it’s about building a coalition. There are many different models about how you might structure contributions to your products that whether your project is more like a cathedral or more like a bazaar, what I think is very important is it be a coalition.
In this era, you’re not going to succeed if you
go at it alone. You’re going to succeed if you understand the larger set of
communities, the larger set of other projects, and needs and customers and
entrepreneurs that exist around you, and think, “How can I build a coalition to
solve a problem that people really care about?”
I think if you start from that point about the
community you want to build and the problem you want to solve, it ends up being
a more powerful starting point than, “Hey, what’s a really cool piece of
technology I could build?”
Michael Schwartz: I think that’s a really good advice.
Geoff Schmidt: The other thing I’d say is, I think, through podcasts like Open Source Underdogs, I think it’s getting easier and easier to start these types of businesses.
I think if you go back, even not that many years,
a lot of the ways that you would build a business like this will really expect
a little bit unknown, and that made things a lot harder.
For example, can you find executives that
already understand your business model, are there pre-stablished like marketing
and sales playbooks that you can run, are there reference points that you can
look at in terms of pricing and packaging to understand what’s worked and what
hasn’t worked.
Or even, is there a community for you as an
entrepreneur, where you can meet some other folks that have been down this road
and talk about your experiences – all those things have gotten a lot easier. It’s
a model that is increasingly well understood. I think it’s not just the future
but also the present at this point.
I think it’s been really rewarding, it’s been a great experience for us, I think they can require some patience because in open-source business models, you have to succeed twice: first, you have to build the great open-source project for your technology, a great community around it, and then, you have to build a great business around that.
But if you have the stamina to do it, not only are they some of the most rewarding business I think, and not only do you have this incredible tailwind behind you with your community and your supporters if you built a good coalition, but additionally, I think they have the potential to be some of the most capital efficient businesses, and have some of the best economics.
Because if you structure your business right, you
have some of the best parts of a B2C business on one side, where you able to have
a big internet community, and a big group of supporters that will have your
back, but with some of the B2B economics on the back end.
You just have to do the work to understand what really is the right way to benefit your users and serve the community, because it is a business model, where you have to start from the point of view of stewardship, asking how you build a community, asking how you adopt the perspective of making the best use of the resources and position that has been entrusted to you in the community, but I think that’s really fun for people that are attracted to that.
Closing
Michael Schwartz: I think those are really good advice, so, thank you so much for sharing.
Geoff Schmidt: Of course.
Michael Schwartz: And thanks for the Apollo team for logistical support.
Transcription and episode audio can be found on opensourceunderdogs.com. Music from Broke For Free and Chris Zabriskie.
Audio editing by Ines Cetenji. Production assistance by Natalie Lowe. Operational support from
William Lowe. Transcription by Marina Andjelkovic.
The Twitter handle is @fosspodcast.
Next week, for our final episode of the season, we have one of the true veterans of the industry, Ed Boyajian, CEO of EnterpriseDB. It’s going to be a special episode, so please, don’t miss it.
Until then, thanks for listening.
The post Episode 41: Apollo GraphQL, revolutionizing how developers write modern applications, with Geoff Schmidt, CEO and Co-Founder first appeared on Open Source Underdogs.
View all episodes
By Open Source Underdogs
5
1111 ratings
Geoff Schmidt, CEO and Co-Founder of Apollo GraphQL, says you don’t get to pick your business model, you get to pick your problem. As part of the team who authored one of the most popular monolithic JavaScript rapid application development frameworks, MeteorJS, Geoff describes how they applied their experience to address an even bigger challenge–how to build more flexible backend data services.
Intro
Michael Schwartz: Welcome back, Underdogs. I’m your host, Mike Schwartz, and this is ep isode 41, with Geoff Schmidt, Co-founder and CEO of Apollo GraphQL. Geoff and his team have a gift for looking at the same problems we’re all looking at, and coming up with inspired solutions. After developing Meteor JS in 2011, they developed the Apollo GraphQL platform, which has coalesced and expanded its community in just a few years.
Geoff has some tactical advice on how to engage
with your community to build an amazing business. Apology in advance if there
are a few audio blips on this episode.
If you like the podcast, please help us get the word out. Like it on iTunes, or even tweet at a link on opensourceunderdogs.com. Our handle is @fosspodcast. Enough shameless self-promotion, let’s get on with the interview.
Thank you so much for joining the podcast today.
Geoff Schmidt: Of course, it’s a real pleasure.
What Is GraphQL?
Michael Schwartz: What is GraphQL, and how does it relate to the Apollo GraphQL platform?
Geoff Schmidt: GraphQL is kind of like a query language for the cloud. We’re in an interesting situation right now, where, if you go back 5 or 10 years, the way we built apps was really different. You might have a web server and a web server might connect to a database or two. And then, on the front end, you might have a web browser, maybe even a mobile app.
But now, we’re in this situation that is a lot
more complicated, where people are expecting more and more from applications. The
applications have a lot more of a richer interactive experience, they do a lot
more, they’re also available on more platforms, and at the same time the
services in the cloud that back those apps got a lot more complicated too. It’s
not just a web server and application server, it’s a whole bunch of different
micro-services typically.
And so, you’ve got this problem of, how do you
connect all of those devices, all those apps and all that sophisticated
functionality to all those services that exist in the cloud. And the old way of
doing this was with REST APIs. REST APIs require that you write a bunch of
custom code basically for every screen in your app, probably a new REST
endpoint for every use case.
And with GraphQL, it’s a flexible query language,
so an app developer can ask for any combination of data that they need out of
the cloud, and you don’t have to write custom code anymore, like you would with
a REST API.
So, one way of looking at it, it’s a better way for app developers to be able to query all the day that exist in the cloud, it’s a much better experience for the developer. Another way of looking at it is, it’s a way that an organization can build a connected map of all their data and services in the cloud, so you can have one central organizational source of truth of all those resources.
And I think another way to look at it is, it’s almost like an abstraction layer for the cloud. It’s a way that you can, even as you are writing your applications, even as you are building your micro-services, you can keep like one consistent stable map, so that really gives you the ability to write a lot more apps, build a lot more cloud services, and evolve your all infrastructure really, in a flexible and more principled way, now that every app has an API inside of it.
Origins
Michael Schwartz: Can you walk us back to 2011. Meteor development is founded – where were you then, and how did you develop that into Apollo GraphQL?
Geoff Schmidt: Sure. This whole journey started for us back in 2011, we were in one of the early Y Combinator batches back in summer 2011, and I was meeting a couple friends, and we had a lot of different ideas, but what we wanted to do is, when we got into Y Combinator, we discovered that all of the people in our Y Combinator batch were really struggling to solve the problems of modern app development.
2011 was kind of a tipping point, when the world
went free on rails with PHP as enough, to “Wait a second, now people have
bigger expectations about the user experience, where they were trying to
deliver that user experience.”
So, what we decided to do is, me and my co-founders, Matt Debergalis and Nick Martin, we’d work on a variety of other projects together, each has been trying to build a different combination of apps, or open-source projects, or SaaS products, and we thought, “Can we take everything that we know about building modern applications and put it into a reusable framework?” That would help people build apps faster.
That gave birth to Meteor JS, which we launched in early 2012. And it grew over the next couple of years to become one of the top 10 most startup projects on GitHub.
When we launched Meteor 1.0 there were local media
meetups, I think 134 cities around the world on the same day. So, we had big
success with this monolithic JavaScript open-source app development framework. And
we were able to build a profitable business on top of Meteor JS with Galaxy,
which was a hosting platform for Meteor.
But what we started to realize, as we got toward
the end of 2015, there was a bigger opportunity, because we were finding that
people wanted to connect Meteor, not just a MongoDB – which was the database that
came in the box with Meteor – but they wanted to connect it to all sorts of
different sources of data and services in the cloud.
We also found that people wanted to build app
experiences that were not just JavaScript in the web browser, but across any
number of different mobile platforms, and increasingly, like all kinds of new
stuff, these IoT platforms, all these things were happening.
And we really said, “If we could take the technology
inside Meteor or the ideas, architectural ideas inside Meteor, and put that in
a form where you can use it not just for new applications like Meteor for any
app, and you can connect it to any source of data in the cloud, not just a
particular database, and you can push into many platforms, not like just one
front-end, written in JavaScript, then, it would have an even broader
applicability.
The other thing we saw was that Enterprises were
starting to adopt Meteor JS, and we were getting much more familiar with the
needs that you see when you are building highly-scaled applications of
Enterprises, not to scale in terms of how far the technology scales, but scale
in terms of how you have larger code bases, larger teams. And so, that led to
us starting to research like what would Meteor 2.0 would look like, what would
the component to that be. We’d also seen the rise of react.
And we’d seen that something like react, that’s
incrementally adoptable, where instead of having to build a new application,
you can add it to an existing application, quickly get up and run it, and
quickly get some proof points – we saw how powerful that was for growth. So, we
thought, “Can we build a new data layer for Meteor that takes everything we learn
from the whole experience with Meteor that is a very powerful open-source
project?”
Everything we learned from Enterprise customers,
everything we learned about the proliferation of back-end services in the cloud
and new front-end that people wanted to use, and put it in an incrementally
adoptable form. And that’s the end of 2015 I guess.
And that’s when we heard about GraphQL. GraphQL
was just what we needed to work on this new project, which is what we were calling
the Apollo project, because Meteor has been so tied to MongoDB, whereas
GraphQL, this whole idea is, it’s this database agnostic abstraction that lets
you talk to any number of different databases or cloud services.
We set it to take some of the core ideas or learnings from Meteor, make it speak GraphQL as a query language, build something that is very easy for people to drop into existing applications. And then, we started launching the first Apollo open-source component in early 2016, and it’s been really amazing couple of years as more and more people adopted this technology. I think it’s really exceeded any expectation we had for it back in 2016.
Sales
Michael Schwartz: Can you talk a little bit about how your sales processes have evolved, because I would imagine initially there was a lot of organic inbound Enterprises saying, “Okay, we want to use this software, but over time, how has that changed and adapted to the demand?”
Geoff Schmidt: I think we have seen a trajectory that’s pretty typical in the sense, yeah, to your point. Some of our first customers were people that were already very sophisticated users, very sophisticated early adopters, who were using Apollo at scale in the Enterprise, as well as people maybe who were small, midsized businesses but had a strong vision for what they wanted to do, and they wanted to get a technology partner for their vision.
Some of those first customers, there were
various things that we helped them with, but in a lot of cases, it was the
relationship with us, maybe some code development on the open source, us carrying
the pager for their assistance maybe.
There’s a couple of different ways those things were
structured, but what happened was, more and more of our businesses shifted
toward the additional tools and services that we were able to provide around
the core Apollo Client, Apollo Server open-source offering.
We have a product called Apollo Graph Manager.
Graph Manager is essentially the control plane for a data graph, so, we have Apollo
Client, Apollo Server. It’s basically the date plane, it’s the stuff that goes
in your data center to answer queries, the stuff that can’t go down, stuff that
handles all of your personal data, all your sensitive business data.
But what we found is both as companies scaled the Graph, they go from just a couple developers to 10 developers, to 100 developers, to 1000 developers. There is a lot of additional management tool that you want. There’s also a bunch of architectural best practices that are really helpful. It’s really helpful to put your Graph schema in a schema server, have a central source of truth for the structure of your Graph, how it is changing over time, build workflows, and processes, and governments around that.
At the same time, one of the best parts of the Graph tool is the tooling that’s possible around it. And that tooling is super valuable very early in the development process as well. And so, the SaaS services we built that are essentially souped-up set of developer tools, and even more so, a control plane for a scaled enterprise data graph.
That’s all packaged up in a SaaS service we call
Graph Manager. More and more of our business now is Graph Manager. And what
we’ve done is, we’ve created both an Enterprise offering around Graph Manager
that comes with the full 24/7/365 SLA for the whole Apollo platform, covering
all the open source, all the SaaS, as well as our support and expertise. As
well as some like in Enterprise Edition of Graph Manager that has features like
single sign-on, some of the things that are Enterprise specific requirements.
As well as having, we go all the way down to a $49
per seat per month offering that anyone can buy online with a credit card
because you want the support through the whole development cycle.
And we also have a freemium offering. If you
just want the developer tools for the earliest stage of development process, you
can use it for free. We’ve really tried to understand what the entire user
journey is from the moment you write the first line of code and start exploring
GraphQL, all the way through to when you have a scaled graph in an Enterprise –
it’s the strategic asset.
We tried to understand how people want to buy and how people want to partner with us at each of those stages. And it’s an ongoing process, but we’re building our packaging around that user journey to try to accommodate each stage in the journey.
Revenue
Streams
Michael Schwartz: What would you say the current breakdown is of SaaS vs. license revenue? Which part of the business is more important today from a revenue perspective?
Geoff Schmidt: I think there’s some open-source companies where the service offering is a bolt-on, like maybe it’s a nice to have. But it’s not really that critical. Or, in some cases, something was included primarily just to drive renewals. That’s not the case for us. We find that the Graph Manager, the SaaS tools are very important to people as they scale, and also are something that people really value early in the process.
I would say that almost every customer is using some form of the SaaS tools. Now, in terms of what’s the breakdown of revenue versus people are purchasing online versus people are purchasing more Enterprise subscriptions, Enterprise subscriptions are a big part of the revenue. Right now, from a customer count point of view, it is more online purchases, but most people are using some form of the Graph Manager, though there are exceptions to that.
How To Align With The JavaScript World?
Michael Schwartz: JavaScript is the largest community. Do you have any insights on how other open-source companies can align with the JavaScript world?
Geoff Schmidt: JavaScript is really about the rise of app developers, and it’s about the rise of accessible app development. It’s one of the easiest languages to learn, and there is a huge amount of demand for more sophisticated websites built in JavaScript. A lot of what drives the rise in the JavaScript is, there’s this whole world of apps that are written on kind of this LAMP stack derivative frameworks that date back to, in some case, the nineties, like PHP, Ruby on Rails, ASP. Net, Spring. Like the LAMP stack approach to building applications.
And what’s going on right now is, a lot of these apps that were written on those frameworks are getting re-platformed onto a more modern app data stack that includes React Apollo, some of these other components are going to be building a modern experience. I think that the way to think about how you align with JavaScript is to think about how you align without movement toward like modern app development. The thing is, most of the time when a company is going through that transition with a re-platforming, it’s part of a larger modernization effort.
They are often evaluating other technologies too,
and they are thinking about, “Hey, is this a time for bringing Kubernetes?” Or,
“Is this a time for bringing a different version of mobile development?” Is
this a time to go to different platforms?” I think like every offering’s going
to be different, you either have an axis with modern app development, or you
don’t. If you do have an axis with modern app development.
I think it’s really important to understand like the JavaScript constituency is going to be one of your biggest users if you can understand really what their pain points are.
It’s very driven by community. I think front-end app developers, by nature, they value design, they value community, there’s a really great community there, they are collaborative and positive, community that is more diverse than Symantec, it’s more accessible than Symantec.
Making an investment in how you meet that
community where it is, understand what the values of that community are, and maybe
build some relationships with the leaders in that community, I think can really
help you reach those app developers.
The other thing that’s important is to
understand that it’s a community that cares a whole lot about user experience,
maybe more so than some other communities. It’s what you do every day is an app
developer, you think about how you deliver great user experience to users. It
tends to be people that value good user experience.
I think those are some of the values of the community that can help you get more mindshare more quickly if you do have a product that is related to modern app development.
Benefits Of Open Source
Michael Schwartz: Has the open-sourcing of the code materially benefited the company?
Pricing
Geoff Schmidt: Absolutely. Apollo would not exist today if we were not open-source. I don’t think there would have been anyone to do this, other than as permissively licensed set of open-source libraries.
Michael Schwartz: You were mentioning pricing before, and actually I think pricing is really hard for Enterprise startups. In your industry, it sounded like you had a logical gating mechanism, like you mentioned number of developers. Do you have any advice – going from 2011 to today – any advice on how do you find the right price and the right gates for your software?
Geoff Schmidt: Well, it was a journey for us to get here. We originally priced based on query volume, so the number of operations that you performed on your graph. And the reason we went that direction is, we thought of it as utility, like AWS. And we thought, “How cool it would be if you had a very predictable, very simple way of understanding, “Hey, here’s what my costs are going to be.” If you told like electricity, or water or cloud computing. And we thought that was a model that everyone was really familiar with, that would feel like a natural way to purchase infrastructure like a data graph platform.
What we learned was that query volume pricing
wasn’t very well aligned, either with how people wanted to buy and budget for
technology in this case. And also that wasn’t very well aligned with the value
that we were providing.
We had customers that were doing maybe billions
of queries a month with a small team, and we had customers that were doing maybe
millions of queries a month with a much larger team, for like maybe an even
more valuable line of business.
Like the business I associate with the query is
so different across maybe a B2C app that is like mostly freemium, versus an
internal line of business application. So, that lack of value alignment, which
kind of manifested it as the platform would get way too expensive, way too
quickly for some people, whereas other people that were driving a lot of revenue
from the product and getting a lot of value were very happy with, they might
only be paying $2 a month.
It manifested as a churn of some of our largest
customers as the query volume pricing just got unaffordable. It manifested as a
lot of people who had to contact sales to better understand the pricing. It
also manifested as longer sales cycles because it meant that we were forcing
people to predict their usage of the Graph far into the future, because if
you’re going to adopt this like core piece of infrastructure, you really want
to have a good way to understand what your costs are going to be.
If you are looking at this thing and you are
thinking, “Man, this is probably going to expand to be all of my app
development and all of my traffic.” And especially if it’s a new technology,
where you don’t necessarily know the estimate, how many queries are going to be
doing, like how many react components might use this, how many queries might
each one do, that’s really scary, and it slows adoption and lengthens the sale
cycle.
So, what we did was, we listened to customers to
understand what’s the most easy and natural way for them to buy what just feels
like a great experience for them. And what we found was, at the early stage of
the journey, especially if you’re doing a self-service purchase online, or if
you are an internal manager that is just buying it for your team, thinking
about it as developer productivity, see pricing is A very natural and easy way
to understand it because it’s proportional to the investment you’re making and
developing your application proportional to your team size.
It’s also pretty easy to predict and plan, and you
could plan it alongside your other cost. And as we get into some of the enterprise
tiers, there’s a platform fee as well, which is based on sort of the overall
intensity of use of the graph, which is a couple of axes.
Query Volume is an axis there, but it’s only one
of several axes that we used to understand, like, “Hey is this an individual
team?” Maybe it’s a whole business unit, maybe it’s a whole much larger company
that’s all family different brands. We found it really startling with an
understanding of how people want to buy and aiming to serve the customer,
rather than saying, “What do we think our users might want?” Or saying, “What’s
the easiest way to plan our business?” was really, I think for us the master
key in fighting the right pricing.
Pricing Process
Michael Schwartz: To get you to your new pricing model – did you appoint somebody who is heading up that task, and who made the final decision around what to charge?
Geoff Schmidt: It was my co-founder who’s also our head of product. It was a process that involved many people in our team, many customer conversations, listening to what we were hearing from the sales team, listening to what we were hearing on the developer relations on open-source side. A lot of conversation inside the team, and ultimately, it’s one of the decisions that is hard to change, that you don’t want to be constantly changing your pricing, at least your pricing axes. At some point, you have to gather information you can, and make a decision to commit to it, and take it from there.
Open Core?
Michael Schwartz: Would you say that you are open core?
Geoff Schmidt: I would describe us as a complementary product model, so we have our open source. And right now, we don’t hold anything back on the open source. Could there be open core Enterprise features in the future? Yeah, maybe. And we’ve heard some requests that it might be a good fit for that model.
But currently, open source is just open source,
but what we offer is a SaaS service on top of that. I think of it as a
complementary product. The way I think about that from a business point of view,
if I think about advice I give open-source entrepreneurs, I think your business
model as an open-source company is not necessarily something you can force. Like,
I don’t think you get to pick your business model, I think it’s more like you
get to pick your problems, like pick what you are building. And then, that will
have a natural business model associated with it.
I think that there are some things that are open
source that are just really hard to monetize. There’s a lot of things that are
100% in a view layer on the front-end, there’s just not a natural way to
monetize that. These things, their ultimate destiny, at least I think for the
foreseeable future, and in a lot of cases, they are just going to be open-source
libraries.
There’s other things that can really naturally
be monetized by selling supportive services from day one. There’s other things,
like get offering in an open-core model.
There’s other things that very naturally can be
monetized by saying, “Hey, I have some open source.”, but any using this open
source, many of them will want the SaaS service. I think Git and GitHub is a
great example of that.
I think you have to start with what the natural
structure of your solution is, and ask, “What are the pieces of this that your
users would like to be commercial?” And, “What are the pieces of this that your
users would like to be open source?”
And follow what really does right for the user in order to find out that right model. I think if you try to go the other way and say, “I’m going to try to force particular business model on this because that’s my strategy.”, I think you’ll end up creating worse experience for the user. And I just think that the world we are in with dev tools and the internet today, there are so many opportunities. I think you’re going to see competition that correctly shapes product, I think it is going to win with the correctly shaped business model.
Is There Amazon GraphQL?
Michael Schwartz: Is there an Amazon GraphQL hosted service similar to what you’re offering?
Geoff Schmidt: Amazon does have a GraphQL offering called App Sync. App Sync is more focused on mobile development, and it’s more focused on getting mobile developers a great way to access all the data and resources they have inside Amazon. It’s a little bit more of a back-end as a service. Maybe that’s not a quite right way to study because it can do so much more inside Amazon.
That’s different from what Apollo is, which is
focused on integrating many different data sources in the cloud as some of you
can incrementally adopt. You can add Apollo to any existing application or
stack, whereas App Sync is designed a little bit more for new application
development typically, so they’re actually complementary.
It makes a lot of sense to say, “Apollo is my
data graph integration layer, and then maybe I could have App Sync with some of
my back-end services. With technology like Apollo Federation, they are good
frameworks for how we can think about federating multiple GraphQL services
together to build one graph.
Some of the details that are still being worked out because a lot of this is a new technology. But, conceptually, I see them as complementary products rather than competitive.
Would Amazon GraphQL Be Good Or Bad?
Michael Schwartz: Let’s just say that Amazon takes the Apollo open-source server and lunches Amazon Apollo server service – would you view that as a positive or a negative?
Geoff Schmidt: I think the more the merrier. I would love to see more people running Apollo server on Amazon. And if Amazon helps them out, that’s great. We’re focused more on how you scale the graph, and that has a lot more to do with workflows, and the control plane, and a schema registry, a bunch of other things that are like really different from a SaaS offering, and really different from Apollo Server and Apollo Client.
I think the more people are building services on top of GraphQL, and the more GraphQL grows, the more people are going to need solutions for managing large GraphQL, like Apollo Graph Manager. But I think it’s a positive for us potentially.
Open Source V. Commercial
Michael Schwartz: Do you ever feel any friction between, when you’re introducing a new tool, and between should this be open source, or should this be commercial? And how do you decide which way to go?
Geoff Schmidt: For us, we have a pretty bright-line. We start with, “Does this naturally exist inside the SaaS offering or does it just naturally exist inside the open source?” And I think that’s been a really reliable benchmark for us.
On some level, that’s just a technological fact,
like where to go, where to live, in our case, because we have a SaaS model
instead of being open core currently, but I think there’s some things that we
learn along the way that I can talk about.
I think one of the core ideas is, companies who
want to own their data graph, this is a very important investment for them. And
they don’t want to feel beholden to an outside vendor, just for the continued
existence of that, and maintenance of that thing.
At the same time, they also want to see strong
vendors with viable business models because they want to know if there’s going
to be somebody there to support them. I think your challenge as a vendor is
helping craft that right relationship with your customer, so they feel comfortable
and secure.
And they trust both of it, you’re not going to be in a position with too much power over them, but at the same time that they trust that you’re going to be around. It’s very rational considerations that customers have when they’re selecting a solution like this. And downstream from that, focus on customer trust, and just really trying to understand what would you want if you were that Enterprise that was purchasing the software, or adopting that solution whether it’s open-source or commercial.
I think that some of the principles we found are
what’s inside owning your graph, controlling your graph, it’s important that
people own the entire data plane, so everything from when the request comes in
all the way through to when it’s answered by your services and the responses stitched
together and sent back down to the client.
You want to feel like you’re in control of the
uptime of that. You want to feel like you’re in control of the security and the
privacy associated with that. You want to feel like if there’s ever an issue,
you can look under the hood, read the code, understand what’s going on, and fix
it without necessarily waiting for round trip from vendor, at the same time, as
you want to have the vendor on a 24/7/365 pager rotation for you.
So, when we think about the features that relate to keeping your system secure, and private, and up, to me those are the things that have to be open source. When you think about the things that relate to how we manage the workflows and processes around it, where maybe it is tolerable for some of those aspects to exist inside of a SaaS platform, and maybe it’s even better. Because you have a supplier that’s constantly keeping that up-to-date data adding new features.
And it’s delivered as a managed service to you. Those are the places where I feel like the SaaS stuff fits really naturally. And so there’s some nuance and complexity there about how we’ve been sharing that. So, for example, one of the things that Graph Manager can do is, it can manage the deployment of your Apollo gateway instances. If you are using Apollo Federation to manage the whole constellation or fleet of these different GraphQL back-end services in a federated architecture.
So, to do that, what we do is we push Graph Manager
push the configuration that those Apollo gateway servers are going to need to pick
up into a highly-available, global distributed CDN.
That way, we are doing the analysis of how is
this going to affect my uptime to have this dependency on this other component.
You can see even if Graph Manager goes down for 30 seconds, it’s not going to affect my ability to scale up and down my servers, because we’ve found a solution like the CDN to ensure really high uptime for our services.
GraphQL Foundation
Michael Schwartz: Last year, you announced the GraphQL foundation, I’m wondering is that self-sustaining, and what role the foundation is playing in the ecosystem?
Geoff Schmidt: The GraphQL foundation, that was put together by us together with Facebook, and the Linux foundation, and a few other great founding partners coming from Facebook, the folks that originally wrote the GraphQL stack and created the GraphQL language.
The foundation is self-sustaining, it is one of
the auspices of the Linux Foundation. The way I see foundations, they are the
keepers of the specification. It’s really important that a technology like
GraphQL that we have a way in industry to evolve, going forward, while
maintaining interoperability.
I think in the early days of GraphQL, there were
a lot of questions about the relationship between GraphQL and Facebook. There’s
a lot of positives there because there’s a proof point about how GraphQL has
powered applications at massive scale at Facebook for years. And I guess people
have a lot of confidence that it’s a good, technological direction.
At the same time, too much control by Facebook that isn’t the developer tools company I think was a little bit of a concern for some folks. And now that we have a foundation that can be the custodian to stack, I think that’s a development that’s given folks a lot of comfort and confidence.
Changes In Enterprise Software Market?
Michael Schwartz: The Enterprise software market has changed a lot in the last 10 to 20 years – can you talk about how you think vendors of open-source software should think about their strategy today?
Geoff Schmidt: I think the key thing to understand first is, to the extent, how you are thinking about how you monetize your open source, who is the buyer, is the buyer going to be an end-user, in which case you probably have more of a bottoms-up motion, where it’s probably a product-led motion, where you’re focusing very much on the user’s first moment experience, and what the value proposition is for that first credit card swipe.
And then maybe after that, thinking about what
are the layers that drive and upsell the Enterprise possibly as the graph
grows, and maybe what starts being used by multiple teams, or whatever your
product is.
There’s another approach that can also work well
I think, where, if the buyer is more naturally maybe a leader inside the
infrastructure team, or maybe another executive where it might make sense to
enter around the 1500- $50,000 price point, where it’s more like a
comprehensive Enterprise subscription offering.
I think the thing to understand is what really is the adoption model of your software inside the customer, and understand is it really driven by end-users that want to purchase easily online, or is it driven more by the need to have a business relationship and a vendor relationship. And I think that ends being, in my point of view, the driver of how you build your go-to-market strategy.
Advice For Open-Source Entrepreneurs
Michael Schwartz: Last question, any advice for new entrepreneurs, like the people who are starting this business around an open-source product, what advice would maybe you give yourself, if you could go back 10 years, or so, 9 years?
Geoff Schmidt: It’s a good question. I guess I would say they’re not the easiest businesses to start but they’re some of the most rewarding. Because you get to hold an incredible community, and you get to touch a lot of people, you get to do it very quickly at internet scale. And I think one of the idea about doing open source right is, it’s about building a coalition. There are many different models about how you might structure contributions to your products that whether your project is more like a cathedral or more like a bazaar, what I think is very important is it be a coalition.
In this era, you’re not going to succeed if you
go at it alone. You’re going to succeed if you understand the larger set of
communities, the larger set of other projects, and needs and customers and
entrepreneurs that exist around you, and think, “How can I build a coalition to
solve a problem that people really care about?”
I think if you start from that point about the
community you want to build and the problem you want to solve, it ends up being
a more powerful starting point than, “Hey, what’s a really cool piece of
technology I could build?”
Michael Schwartz: I think that’s a really good advice.
Geoff Schmidt: The other thing I’d say is, I think, through podcasts like Open Source Underdogs, I think it’s getting easier and easier to start these types of businesses.
I think if you go back, even not that many years,
a lot of the ways that you would build a business like this will really expect
a little bit unknown, and that made things a lot harder.
For example, can you find executives that
already understand your business model, are there pre-stablished like marketing
and sales playbooks that you can run, are there reference points that you can
look at in terms of pricing and packaging to understand what’s worked and what
hasn’t worked.
Or even, is there a community for you as an
entrepreneur, where you can meet some other folks that have been down this road
and talk about your experiences – all those things have gotten a lot easier. It’s
a model that is increasingly well understood. I think it’s not just the future
but also the present at this point.
I think it’s been really rewarding, it’s been a great experience for us, I think they can require some patience because in open-source business models, you have to succeed twice: first, you have to build the great open-source project for your technology, a great community around it, and then, you have to build a great business around that.
But if you have the stamina to do it, not only are they some of the most rewarding business I think, and not only do you have this incredible tailwind behind you with your community and your supporters if you built a good coalition, but additionally, I think they have the potential to be some of the most capital efficient businesses, and have some of the best economics.
Because if you structure your business right, you
have some of the best parts of a B2C business on one side, where you able to have
a big internet community, and a big group of supporters that will have your
back, but with some of the B2B economics on the back end.
You just have to do the work to understand what really is the right way to benefit your users and serve the community, because it is a business model, where you have to start from the point of view of stewardship, asking how you build a community, asking how you adopt the perspective of making the best use of the resources and position that has been entrusted to you in the community, but I think that’s really fun for people that are attracted to that.
Closing
Michael Schwartz: I think those are really good advice, so, thank you so much for sharing.
Geoff Schmidt: Of course.
Michael Schwartz: And thanks for the Apollo team for logistical support.
Transcription and episode audio can be found on opensourceunderdogs.com. Music from Broke For Free and Chris Zabriskie.
Audio editing by Ines Cetenji. Production assistance by Natalie Lowe. Operational support from
William Lowe. Transcription by Marina Andjelkovic.
The Twitter handle is @fosspodcast.
Next week, for our final episode of the season, we have one of the true veterans of the industry, Ed Boyajian, CEO of EnterpriseDB. It’s going to be a special episode, so please, don’t miss it.
Until then, thanks for listening.
The post Episode 41: Apollo GraphQL, revolutionizing how developers write modern applications, with Geoff Schmidt, CEO and Co-Founder first appeared on Open Source Underdogs.