We’re chatting with Steve Peak, Founder and CEO at Storyscript, about his ambitious project which aims to be the new standard in developing software. Storyscript is a top-level programming language and platform that is specially designed for data flow between highly-reusable components (e.g. microservices), written in any other programming language.
Watch this Episode on Youtube
The Full Transcript
Darko [00:11:23] Welcome to Semaphore Uncut, a place where we talk about cutting edge technologies and people who build them. My name is Darko. I’m your host for today, and with us we have Steve Peak. Steve, please go ahead and introduce yourself.
Steve [00:11:39] Hi. Thank you, Darko, for having me on here, to your show. I’ve been an entrepreneur and engineer for a decade. It’s been a really great time, being kind of out of the big business and working from more of a holistic approach. My journey started pretty early; I built a point of sale company. It never really took off; there were a lot of learnings in there. I spent about six or seven years in that company. Customers are asking for things like long running business logic and long running asynchronous programming. As an engineer, you want to say yes to these challenges but as we all know, the client often wants a change, you constantly update the code, and then they don’t want to pay for it, or pay the full price tag, which you’re worth.
It was a challenge that I wanted to solve, so I prototyped the first thing. It’s called Storyscript, but it was early to the industry, so I put it on the back burner. I then quickly jumped on to building a company called Codecov, which grew quite well in the developer ecosystem. It was a really great pleasure to bring that to developers and learn a lot from the industry, but also just provide a really great dev tool that I was very passionate about developing for people. I’ve recently exited that company; it’s led by Jerrod Engelberg and a number of other developers. The crew is fantastic. They are going to build that company into a great product. I continue to take on the legacy of it.
I am now focused on Storyscript. We’re a team of eleven now, actually, and we’re looking to transform into application development. It’s a big, tall order—a big ambitious goal— but someone’s got to do it. And I’d love to go over how that’s going to be possible during this chat.
Darko [00:13:27] You mentioned Codecov, and I think that a lot of our listeners and viewers have, at one time or another, heard about or used the product. Maybe we can give them the opportunity to hear a more detailed story about when it started, and what was the journey.
Steve [00:13:49] Starting Codecov was almost accidental. When I was working on the point of sale company, I was getting heavily invested with testing—and again, we all know the importance of testing. And so one of the things that I felt was missing in the ecosystem coverage was a tool that merged reports, because I was doing many different types of tests, whether it be unit tests, or integration tests, or also different types of Python packages, or adding my front end to it. I really wanted that coverage, and there really weren’t any tools out there that could merge things properly.
I ended up creating Codecove. But it like a home-brewed weekend project, that I thought OK, it’ll be fun to do this, and I need this to be valuable. And then I was talking to the developers, and I went to the pipeline community and just tapped on a couple people’s shoulders (and in IRC at the time), and said “Hey, do you want to join in? I mean, just kind of jump on board.” And eventually they were asking for new features, and they started to wonder if there was a name behind this thing. I didn’t have a business name; it was just a small tool. It didn’t take more than two or three weeks before I thought, OK this is a business. There is a demand for this, and it’s very prevalent. So it was brewed—I guess I just specifically had the need and desire for the tool that I wanted as an engineer myself.
Darko [00:15:11] Great. Well, I love those stories where people, in a very short time frame, figure out, OK so this is really something, and they jump into it straightaway. So that’s how it began, and now it’s grown into a company. Then you decided to move to the next thing, which is Storyscript. How long did you work on Codecov before you passed it along?
Steve [00:15:44] I was the sole employee of Codecov for about three and a half years. It was a really wild journey. I was specifically focused on the stack itself, and the technology, and over the course of the three and a half years it shifted more to doing sales and support and other things, and unfortunately, the technology was starting to not get my primary attention. And that was evident in the lack of what I used to do—I used to be able to get a customer asking for something and build it that day. And deploy that day. That was something I was really proud of doing, it was really fantastic and it allowed us to grow really fast, but at a certain time that’s not sustainable.
And so, since I was focusing on all this other stuff, it came to the point when I felt that the company needed to grow beyond me. I had treated it kind of like a lifestyle business for a little bit, but still, it was growing and very professional, and I was just lucky to find someone great in my network to take up the operational role and then eventually take up CTO and a bunch of other developer positions—these are all amazing people who are very passionate to build the software, so it’s really nice to have somebody with a whole team to really build up the feature set that we all dream of. Codecov has a very bright future, and it’s unbelievable how much green grass there is. There’s really no company out there, including Codecov, that has fully utilized or captured the audience, and what coverage can be. There are new things in that feature pipeline that they’re unveiling, and it’s very exciting times. And as I said, it’s going to be really great for the developer ecosystem have this kind of tooling, but in the back of my mind, I’m looking at the industry again, and talking to enterprise customers that we had, and talking to developers, and it’s starting to look like we’re ready for something different and new.
The industry is ready, because we’re looking at distributed software and the adaption of serverless technology, too. We’re starting to move to the distributed system, which is fantastic. It’s a lot of work. We’d lose the observability that is beautiful about monolith. And I saw that the industry was coming to a certain point where we’re thinking, OK build story scripts. We can build a language that solves this observability issue. We can go into more detail about that, but I was looking at taking on this challenge and I felt like the industry deserved it, and I felt like the customers and developers themselves were kind of eager to adopt the new technology. And we’d had high-level programming languages for 30 years or so, and maybe not remove them at all, but we need something above that. We need different languages. And so it’s been really exciting to unveil Storyscript and show what we can do with the power behind it.
Darko [00:18:45] We initially spoke when I heard the idea behind Storyscript. I felt there was definitely a need for that. I mentioned the many thousands of YAML files we have look at. It has kind of stabilized and we live with it—you learn to live with some of those things. It doesn’t mean that they’re good, or that they should be that way, but there’s definitely a lot of opportunity. But to stop teasing our listeners, maybe you can go back and explain what your targets are, and what you want to achieve.
Steve [00:19:34] Try to paint this picture with me. Over the course of the last 90 years, technology has abstracted in a massive way. It allows us to focus on what matters most, it allows new developments in the industry like never before. We no longer have to program in assembly low-level languages, and then we introduced high-level languages so we don’t have to really think about memory allocation for these things.
And so now we’re getting closer and closer to the human idea. The first thing I tell you is in my native tongue, “OK, I want a place to upload a video and uncompress it, and I want to extract machine learning topics and put it in a database.” What I just described to you is data flow. However, when I have to program this in traditional languages, as in all high-level languages, there ends up being a lot of devops behind it. And the tooling, these things start to add up, and we call this unnecessary complexity. In the end, all you want to do is just move data between services, and so this whole principle of service-oriented architectures or service-oriented programming is something that the industry is just naturally leaning into or moving towards.
One could argue that languages today don’t really satisfy the service-oriented approach. In fact, if I even talk about the language, for that matter, you really are restricted in some ways. You have to pick libraries in Python, naturally. Yes, there are bindings to other languages. There’s other APIs we call, but naturally there are restrictions.
This is not a full replacement strategy. If we added a new language that described data flow, that was also talking to the cloud providers and not a single computer because, well let’s face it, today’s technology doesn’t run on one computer any more—it runs on many computers. Our resources are no longer CPU, memory—our resources are nodes, databases, ingress routes, right? We need a language that communicates with this new strategy of development that focuses on language.
Storyscript is exactly this. It’s focused specifically on the story of data, hence being Storyscript, it focuses on the business logic. The services that are underneath it are fully polyglot microservices or functions and they run in a serviceless way. So now you can combine Ruby and Python and node microservices and docker with a couple of functions in whatever language you want. And now you focus on just moving data from A to B to C, and this is all done asynchronously, which is beautiful, and it all takes care of your devops for you. So when you do story deploy, like Heroku—we take a lot of inspiration from Heroku and the way they did their thing, but Heroku is actually in the monolith land, and we’re in the distributed land. But when you do story deploy it goes and fetches all your containers and it pulls them down. So maybe you have six different microservices.
It creates all the Kubernetes configuration: the deployments, the replica sets, all the orchestration, and it puts those in Kubernetes for you, and then it manages all your ingress routes and manages like Kafka, the ELK stack, like Prometheus, Grafana, all these quality of toolings for you, out of the box. And of course you can plug and play them as you want.
We’re not trying to tell developers, here’s the one way you have to do it, you have to use Go and it has to be RPC. There’s none of that. Choose the way you interact with your service, define it, and then let’s truly have reasonable services in the industry. And there’s so many different approaches that this will help the developers’ ecosystem, but ultimately it allows us to focus on what matters most—just business logic. Future programming is going to move closer and closer to that concept, where we’re no longer going to be thinking about things that we’re thinking about today. And there’s so much extra abstraction happening that we’re taking the approach that hey, here’s a language. It doesn’t replace other languages. It’s focused on moving data and it uses other languages to do the heavy lifting. And so you get to combine amazing technologies. We can do machine learning in one line of code. You can do a Slack bot, a Twitter bot, GitHub, WebHook handler. We can do all these other beautiful things in just one or two lines of code, and combine all these services together to make one cohesive story of data.
Darko [00:24:05] You explain it very well. But let me let me try to map to what we operate in today. For instance, how Semaphore 2 is built. We have Ruby. We have Elixir, and we have Go. Those are the languages—I would say 90 percent is in Elixir, but we’re combining those together. We are using gRPC on one end, to move that data together between those services and so they can talk, and on the other hand we have Kubernetes, which Storyscript also works with. And then there is the level of complexity and devops—and you know there are many abstractions within Kubernetes that maybe I wouldn’t want to know about it. So maybe my main question is, those services, they’re talking together. What data format are they passing?
Steve [00:25:12] First, we’ve got to break down the application into services. A service can be a database, it could be Twilio, it could be a custom service to trigger a build, it might be a YAML parser. These are all just services. Those services could be defined in any language with any protocols; they might be HTTP, or a Python service. They might be Go RPC. So we have the language Storyscript. We have the Storyscript cloud. It’s the runtime that will manage that data continuity. So, if your service says hey, I communicate with Go RPC, our runtime says, OK, cool, that’s no problem, we’ll just extract this data and then pass it to you and we’ll handle all that communication. So that communication—we use what we call the open mic. With Semaphore you would have to find your services—you may have them done already—in whatever language.
So what you’ve done is you’ve written code, you’ve wrapped in Docker, and now you have the missing pieces. The definition is open microservice guide, which is how the service starts, this is how I communicate, these are its actions, here’s RPC endpoints, and all this kind of thing, here’s the output of the actions and events. So it’s both event driven and action and commands, and all these kinds of things. So Storyscript comes into play with the communication of these things. We’re not replacing RPC, but we’re utilizing it. We’re not replacing HTTP; we’re utilizing it. As well as Kafka, and messages and all these kinds of things.
In Semaphore, you would look at it and ask, when someone clicks a button on our website, what happens? And you start to break that down into services: I have to go to the database. I have to validate this payload. I have to wait for this trigger to happen. All of these could be microservices, but the high-level business logic is exposed, which is very beautiful.
So just to be clear though, we’re not asking engineers to move their current technology stack into Storyscript. We’re not trying to reinvent the wheel and transform our digital ecosystem. That’s not what we’re asking for. We can identify so many things that developers have to do. There are so many things they can have on a backlog. So if you have Semaphore, for example, if you wanted to add some machine learning for how to identify diffs, or maybe we don’t need to run tests because maybe it’s just a YAML or a documentation change. You can dig into your code base to go implement that. You can yield an event, let Storyscript handle it, and use this machine learning model. Use this database, use Lego block style and piece this thing together, and then call it back into your stack. We’re going to build what is the next integration of these kind of things, so eventually, over time we’d like to start to take on new challenges.
I truly believe that the next generation of development will start with developers who will think, well, what should I write in my Storyscript to build an application, and then fill in the blanks later with the high-level or low-level languages under the hood. My application is built on Storyscript. This is my core business logic, laid out right here. Here’s my marketing strategies. Here’s my operational strategies. Here’s my onboarding. These kinds of things.
Darko [00:28:37] That’s clear, and it makes sense. When you were talking about this, you mentioned Storyscript cloud. In terms of deployment, what I’m really interested in is getting rid of those 15K lines of the Kubernetes YAML file. And also that observability, all the things that we have to do manually. So with every new service, you need to write a couple of lines of Prometheus, query language to query something. Then you need to do your Grafana, set up the dashboards, and that’s all doable, but.
Steve [00:29:20] Well, it’s boilerplate, right? And that’s what we identify. Let’s take a generic example—the GitHub API. With the GitHub API, every developer has to utilize HTTP and trust endpoint, they have to call the same actions with the same input and get the same type of output. Of course it’s unique, but it’s the same structure. But GitHub API is more than that. It has error handling, it has rate limiting metrics. GitHub might be down—and we want to identify that. So we might have to go check the GitHub status, to make sure it’s still running. And maybe they want to implement beta features. And as a developer, you think, oh man, we’ve got to go and read all their docs; we’ve got to go troubleshoot. I went through that pain before. It’s not to blame GitHub. But generally, this is how we have to do it.
I propose something different. Why doesn’t GitHub create and manage their own microservice that comes complete with statistics and metrics embedded in it, and comes complete with documentation that leads into other services. So then you have globalized, consistent standardized documentation, which allows doing the typing process to be very beautiful, to call those arguments to get the outputs. But then also, when I call GitHub in my stack it’ll automatically do these boilerplate things, like here’s your Grafana, here’s your metrics. All these things. And in fact, we can start to talk about the deployment a little bit, too. We’ve identified when you look at Kubernetes configuration there is also an extreme amount of boilerplate code in there. For example, you start a service, it goes to this port and has to do these ingress routes—well, with ingress routes maybe you use other technologies like Kong or something else.
They start to work with each other, but ultimately, a lot of this has to do with moving data from the ingress or some other controller back to the service and from the service back out. If you actually take a more holistic view and take a step back—a lot of these are actually pretty standardized. We have a couple of ways of communicating with microservices. It’s definitely push and pull. Do commands, or get it to yield events, right? If we look at the consistencies between services we can start to create a framework around this, and a definition, so when developers end up doing deployments…they shouldn’t. We don’t believe that people should be doing Kubernetes configuration. The runtime should be able to generate those for you and be able to figure out where to put your services, and how it how to manage them. Where are the replica sets, all these kinds of things—it can be a little more intelligent about it. We look at it as being very intelligent, like orchestration framework on top of—or orchestration platform—on top of the framework of Kubernetes.
As Kelsey Hightower and many others have said themselves, Kubernetes is intended to be abstracted a certain way. It is a framework and there should be platforms on top of it. However, if you look at the industry today, most businesses are adopting Kubernetes, which they shouldn’t. What we need to adopt is a platform on top of Kubernetes and utilize Kubernetes the way we utilized Red Hat and Linux and other services. We didn’t have to build Linux or really fully bite into it, as much as we utilize these platforms.
Darko [00:32:29] But we have to wait for that moment, for that platform to arrive, and that could be Storyscript.
Steve [00:32:35] Yes. So just to encompass what we have. The language—which is turing complete, strongly typed, statically written programming language—it comes complete with a lot of cool features like you would expect in an LSP—like a strongly typed language. It has type system, it has auto completing, of course syntax highlighting and integration with your IDE. So it’s got really cool features; it’s really easy to program. It’s also got deep integration across all these other tools. So we have the Storyscript cloud, which is much like Heroku.com or like a self-hosted platform. You launch your story script on the cloud, and then it does all the deployment for you, so it’s a zero devops deployment; that’s what we’re intending on doing.
And now the services come from the Storyscript hub. Think of it like Docker—it’s the foundation, or it’s a place where there’s a registry of services, but we take it to a whole new degree. We have standardized documentation which also gets put into the typing process, which is amazing. So when you go discover service in our hub, it’s the same documentation for every service. It’s just super cool—it’s unprecedented—never really been done before. And then also, like the Docker store, there could be pricing in the future for services that have premium machine learning models, or some awesome compression kit you want to pay for. We also have the ability to cross application anonymized metrics.
Think of it like this. Go back to the GitHub example. GitHub is great at limiting; their uptime is not very specific to a business. It’s just specific to GitHub. So as a company or even as an engineer or the person developing with GitHub (or GitHub themselves), having an understanding of how many people are actually using this is valuable in production. How many times does it error? We should be able to tell you millions of execution data points this thing fails 0.2 percent of the time. And maybe these are the reasons why. This can also help developers build better services. This continuity of the product is very valuable and powerful. There’s the language, the runtime, and the library, which is our hub. It’s really great. And I think these devices—that kind of trifecta you would expect in any language. But ours is more cloud-native development, which is not like much of anything else out there that developers have seen before. It’s quite unique.
Darko [00:35:01] It reminds me of Visual Basic, but in a good way. It’s one of the first languages that I learned, and now twenty-five years later, there is still nothing that is on that level. You have to write HTML, CSS and Kubernetes YAML and a number of other things. You could draw a couple of buttons that whatever kind of button, you write a piece of code—thank you, run—and it runs. So I agree completely on the cloud-native way. There are a couple of things that are handled for you. You don’t have to think about them. But you were describing the language as strongly typed and compiled, and all that. One very interesting element—there are probably similar DSLs and maybe some other areas, but to what does it compile? Almost like an infrastructure, right?
Steve [00:36:04] In a way. With compiling, there’s really two different strategies. Changing one thing changes it into something else. Then transcribing or interpreting is like giving that raw input—generally speaking, that’s how these two things work. It’s neat, when you really think about it. If you define a service in Storyscript it’s one line that says the results equals service, action, endpoint. Now, if I were to write this in the most verbose way in a YAML or JSON, I would say that operation one is a dictionary, the service is this, the input is this, the action is this, the inputs are all these things in these positions, right? But it’s a giant glob of JSON data, and it’s not very readable. JSON in general is nice, but it’s not like I can just skim through and find stuff really quickly. And trying to reposition JSON data is not really feasible, but repositioning programming languages is very feasible. You do it in Vim, fly around, you’re good.
So this language gets compiled into this JSON event logic tree, let’s just call it. It’s like a big tree of saying do this, then do this, then do this. And when our runtime gets that it goes OK, these are microservices. Let’s pull down those containers according to the versions. And then these are functions. Let’s package those up, let’s put those in Knative, open API, or some VM or something. We’ll help you manage these things and choose them.
And then it says OK, here runtime, here’s the manuscript. Here’s the flow of data you need to do. Runtime says cool, we’re going to cache those objects across our runtime. So the data flow is very very fast because the objects are alive. It’s a living system. And then, if I have to go communicate with a service I have this execution path through some internal built-in stuff like let’s string uppercase, and sort, and all these kinds of things that developers are used to, a for-loop. Services like GitHub API will go get this data. And instead of me doing HTTP fetch, like with these headers, or all these things, check the result, maybe do that. All that’s boilerplate; it’s all necessary.
So I locate that information to that microservice. And the microservice may even be a proxy, for that matter. Or it could be an open API spec so it doesn’t even talk to a middleware service, it goes directly to the server. Beautiful. And so now this is an orchestration framework. We orchestrate that data flow between these microservices. It’s quite unique in these ways, but it is compiled into our own runtime and will interpret that ultimate compiled manifest into infrastructure to achieve the goals you need.
That’s ultimately where development is going. I would argue that the future developer—I don’t know how many years—maybe we’ll get there in ten or fifteen years. But regardless, the journey of development is going to end up in a place where they’re named, they’re just commoditized services, like compute, storage, ingress…it’s all the same in the end. And then the developer is just focusing on business logic. We’re just trying to get closer, quicker.
Darko [00:39:36] Please do.
Steve [00:39:40] It’s amazing what we can what we can do. If you go to our website, we have some small demos on there. We’re working aggressively, we’re scaling it like crazy right now, but we’re focused on a lot of examples. In under 40 lines of code, I built an auto-labeling Gmail service with machine learning. It learned from my emails, and then it labeled emails for me, and that was it. In 39 lines of code. And I get it metrics; I get insights; I get logs; I get observability.
I hope that at this point the conversation the developers in your audience will start thinking, well Steve, he kind of indirectly answered the question of observability. Because you have Storyscript, and that is your tool for observability. That’s something that looks like a monolith, but it’s fully distributed. It’s very beautiful. If you have an error, we can show you, coded, it happened right here. Just as you would in a monolith. There are actually really cool things we can do with error management, if you want to go in that direction, too. But observability, to me it comes down to simple observability. It’s the truth of data. Where have you defined your logic? That’s the truth. And so I think that in a distributed system, applying a tool to do tracebacks and to do insights of data flow is ultimately not the source of truth. Your source of truth is actually that kind of like the Kafka, or event streaming, or just some other type of orchestrator. The separation is a very poor design practice, but having a continuity of observability just like a monolith, is very valuable.
Darko [00:41:16] To us, moving from monolith to microservices, that observability is something you really have to learn the hard way. There is a lot of communication between distributed systems, so doing that reliably and knowing what you are doing is very hard.
Steve [00:41:37] Yes.
Darko [00:41:38] We have a couple of years of building distributed systems, so we are learning that. But it’s definitely not easy. And when you were describing how Storyscript is compiled into the JSON tree, that’s very powerful. If you hit the very sweet spot of usability with Storyscript and people are loving it, the backend can be anything. Today it’s Kubernetes, but maybe it can be something higher at some point.
Steve [00:42:18] Yeah absolutely. We could switch software for Docker swarm, you know, even Kubernetes is a little bit of overkill for the use case we’re seeing. Kubernetes is fantastic, and it’s been industry adapted. The platform is open source; it’s Apache 2 license, so you can chuck this on your own Kubernetes cluster and just run it. That’s great. And so we need it to be widely accepted. And then if you look at a CNCF landscape, the Linux foundation, Kubernetes obviously won. And so at some point we’re going to be looking at adopting a lot of the technologies. Storyscript, we’re already member of the CNCF landscape, but we want to be closer and closer in partnership with them on a lot of things, including contributing our open microservice guide, which can be found at microservice.guide website.
Darko [00:43:12] I will check that out. Obviously there are many challenges. If you’ve been running a company for a while you know that, but in terms of these design things and technical challenges, there are those two elements. One is designing the language and features, and caring about usability and all that. And the other side is running that back end, making sure there’s a report, which is the biggest area of linked changes that you see at this point.
Steve [00:43:46] You bring up good points. You have both sides of the fence, right? And so the developers come in from this usability, and they need to make sure they have the trust in that interface to be able to execute properly. And that’s something on our end. But where we’ve positioned ourselves in the market right now, we’re not looking for big production ideas, or things with thousands of lines of code. It’s nice to focus on something small, to test it out to see how users work with the language, and because we’re not a general purpose programming language, we don’t need to do the heavy lifting algorithms or machine learning models or just writing byte data processing for video compression—that’s not what we’re about, or making it for.
So the scope of the project is actually smaller than if you look at it all. I’m not going to make a programming language, because it’s incredibly difficult—and it is. Don’t do it. But if you do it in the scope of being very specific, saying I’m just going to move data and let other things do the heavy lifting for you, that scope becomes a little smaller, and you start to be focused. I think we’ve done a really good job managing that focus—and with the language there’s still so much maturity to do. But we’ve come so far, there’s a lot of usability. In fact, there’s even people using us in production, and we’re shy to do that. But it’s beautiful; it’s really cool.
Considering that we are open source, it’s best for us to contribute with the industry to see what people think we should move it into. We have some GitHub issues open in Storyscript, specifically language. Talking, allowing people to come in, and encouraging them to come and make their input. I think it’d be cool to do that. This is how I think. And we have a lot of discussions about this. We try to keep very transparent about it. But the design of the language is simple. We believe readability and transparency and data flow are key to a successful language, because you don’t have to worry about the heavy lifting. We could focus on the simplicity of data flow, the observability, and these kinds of other things. Runtime is obviously focused on the scalability and about the reusability and all these other things. So the language is designed for the least amount of syntax we can come up with, not aggressively, but recognizing that developers—we don’t want them to have assumptions. We want them to be able to have a transparent view of their data flow and data structures. And also invite new engineers. Let’s get real: maybe 0.3 percent of the world can code, and even out of this 0.3 percent, a significant amount of those have a difficult time doing anything of value.
And I’m not trying to diss on them. We haven’t evolved fast enough, we haven’t evolved strong enough in industry yet. Or to sound like we’re not ready for it yet—we are. And I truly believe that the amount of developers in the industry is not going to stop growing. It’s going to grow more rapidly because of the amount of tooling and the need for developers. It’s obvious. And I would argue that the one way we can get more engineers in this workforce is to lower that bar. We need it to be easier to program, like an AI.
So my brother, for example, he went to public school, public health, and he works with amazing data. He works with R studio in MATLAB and so he understands functional programming a little bit, statistical programming, but I don’t even know if he knows what HTTP is. Where he’s at in his software development lifecycle is really a beginner. But yet he has strong need to build application workflows, long-running asynchronous workflows, and ultimately, their applications’ backend. And yet he does have the resources, and this is a common thing for enterprise, where it’s like all we’re doing is putting out fires as engineers, and yet we have this huge backlog of, I want this. I would love this. I want to try this. Let’s experiment with that and we just say no, we can’t do it. We’re focusing on other complexities, other things.
This can change. We can do better, as an industry. And I’m not the only one doing this. We’re not the only team that’s doing this. But I think we’re one of the only companies that is open source that’s taking this ground roots effort to be developers, saying come to us and let’s work on this together. Let’s fix this problem together, and let’s stop focusing on the complexities of development, and focus on the business logic.
Darko [00:48:18] I really like the point when you share that you’re not aiming to run one thousand microservices right now. At some point, we would probably love to get there, but it’s not our main goal right now. And I think that there is an art in postponing decisions. Following Kubernetes growth, I feel that there is too much complexity that is being exposed. But there is also a skill for postponing decisions, making basic building blocks, and then waiting. Deciding that maybe next year, we will answer how to deal with this. It requires time and a team that can facilitate that process. But it would be amazing if Storyscript could grow slowly in terms of features. Then those decisions would probably be much more mature than “Here is the answer to everything” tomorrow.
Steve [00:49:30] I totally agree. It’s not smart of us to have an answer for everything tomorrow. But the truth is, and I think you’ve identified this as well, there is a significant amount of development that we can bite off right now today, where we are today, being in beta where we welcome anybody to join today. And where we are, you build amazing things. You would be shocked at how fast you can build an AI Slack bot, or a streaming Twitter service, or sentiment analysis. It’s amazing. It’s super fun. You really feel like a developer that has this magical wand. And what’s really cool is that it’s on Kubernetes. You think, wow, I deployed a Kubernetes, I never do that, I didn’t do anything manual and it was really powerful. At some point we’re going to be doing more and more. We can do incredible things—everything we talked about here is phase one planning of the business. And as we grow bigger, and we have a larger team, and we have more impact in the industry, we can do amazing things with machine learning models and in the development process. We can do testing with scaling, with usability, with sharing code, with maybe doing some predictive things, or simulations of stories. If you need to deploy, you can do feature flags, so if you have a large engineering team, you get multiple people working on the same codebase, deploying and production at the same time, and merging them later instead of focusing on one codebase.
The future is going to be very bright, not just for Storyscript, but for all of us in general. We believe that. No engineer is going to sit here and say no Steve, we’re done. This is the tools we have; it’s over. We’ve made it.
It’s going to be easier. All I’m saying is this is probably a big leap, Storyscript. A lot of people think this looks like a moon shot, but I would argue that it’s just the next—maybe the next or the next next piece in this pattern. It’s the next logical journey that development’s going to go on. And I really hope to amplify current developers. Even myself, I am more than happy to go through and build a whole Python application. I think I did in Codecov. I built this whole company up with using Python technology and all those other things. Happy to do it again.
But I’ve identified that I value my time with my family and my friends, and I want to be able to sit back. Look, it’s easier to identify that business logic and implement that in a language that’s built for business logic and that’s really scalable, that’s resilient, that’s flexible, that I can peek under the hood. That’s using Kubernetes, an awesome technology, on top of it. And what we’ve actually done is quite small in the end. The language is one thing. The language is the way to get into the runtime; the runtime is really where all the magic happens. And this is open source as well. So we invite you to go look at what we’ve done and where we’re going and that kind of thing.
Darko [00:52:24] Is there some kind of master plan that covers the next five, ten years?
Steve [00:52:28] Of course. Always. I truly believe that, whether it’s us or not. And this is my goal in life and in this business, to is to create ten times the programmers we have today.
And it’s not just the quantity. We don’t want people to be developing poor things, but focusing on the quality and what matters most. And I truly believe that there’s going to be a massive industry as time is unraveling. Just start to look at the industry—we talked about this a number of times, but just to reach out and identify that technology growth is not going to change. The long-term plan is to say OK, here’s where we are with today’s development. Identifying the element that that haunts our memories. Devops itself is one of them. So let’s look at figuring out how to reduce or eliminate devops. I mean, it’s always going to be around in some way. We’re not saying that it’s going to be gone, but there will be some people that might manage it, and you won’t, as a developer. You’ll focus on what matters most.
And then, looking at work, we take that to the next degree. If I’m writing a story, a business logic, I should have an incredible amount of information brought to my developer experience. Unprecedented, like we’ve never seen before. I have historical data. Maybe it’s even predicting where I want to go with the story. And it’s using it. When I run it in simulated I’m using one month of previous information and looking through. When I’m live coding this, instead of deploying—there’s no deploying anymore—when I’m typing and I go to my next line it uses one percent of traffic to test to see if this works, and if it fails it goes back to the original version.
There are amazing things you could do with this, when you have a language that’s not compiled to one computer and that is run through this cloud-native runtime that is smart, that can be error resistant and resilient. There are amazing things that you can do with that. The future is really looking at making development just terribly simple—embarrassingly simple—because it’s focused on what matters most. And that’s just business logic.
I’d really love to see businesses start to create more reasonable software and own their services. GitHub and Twitter and Twilio and then ImageMagick, and you name it—every company, even Semaphore. And Codecov and everything—they should create a microservice that is highly reusable, that any developer can call in one line of code and use it. In fact, developers are going to see this and get hot by the end of the year because of us. Where you can go in and click one button and try any piece of software. That’s defined by the microservice guide, because we have to have some way to talk about it, but that’s going to really change development. It’s going to allow us to have more reasonable software that has more integration, and standardised documentation. These things are so beautiful. Like staying dry.
Ultimately, we hope for this to be the most inclusive platform for developers, but also the most dry platform.
Darko [00:55:36] Where…do you know the place to enter my credit card, to buy this? (laughs)
Steve [00:55:45] Speaking of pricing, we all have to be very clear on what we’re doing for pricing. So again, with this trend of constantly being transparent, is that our value is in the tooling. You can run this on your own. It’s open core. Our future technologies might have some paid elements, but everything you need to get running is all open source. So we can run on your open Kubernetes base cluster and go from there, or you can use our infrastructure. But we’ll be multi-cloud. We’ll make sure you have uptime really high, and all this kind of stuff. But we are not going to charge you for the hosting. We’re going to send that bill over your way. So, let’s say your Google bill, or if you’re multi-cloud, like your Google Plus Amazon Bill is one hundred U.S. a month. Let’s just say that arbitrarily. Our product is going to be priced per user, and so our pricing is going to be very clear. Our incentives are very clear. We want to make sure the developer has the value. And then, because they’re passing the infrastructure cost over to be shared, it’s an incentive to actually decrease it. Because we’re not making a cut; we don’t want to. It’s our incentive to create that build from 100 to 80 because it shows you that we care about you, and that we’re focused on you and improving. And so now, when our lead engineers or a new employee is hired to our code base, to significantly make development more powerful but also less expensive, then we’re not shy to accept that. You know, if we’re marking up our cloud we’d say this might improve our product by 50 percent, like we dropped our bill 50 percent, that’s awful. That’s bad for business. We have a shared incentive now. So I really believe in the highly transparent pricing that focuses on where our value add is, which is in the developer tooling.
Darko [00:57:30] That sounds amazing. Is there anything I haven’t asked about that you want to share? Maybe about the future, or the next steps? Where can we go and check out these things?
Steve: [00:57:55] If you go to Storyscript.io, you just drop your e-mail in there and we’ll invite you to view the data. You can get documentation at docs.storyscript.io.
I’m the founder of the company, and I’m more than happy talk to anybody about this. It doesn’t matter who you are. I want to talk to everybody. I want to hear what they feel about the platform: the good, the bad, the ugly, and everything in between. I want to share this vision; I want to share this experience with people, to learn from them and also so they can learn from us. We’re trying to scale up those efforts build a community around the product, because ultimately, we believe that any strong programming community can found it. I’m very ambitious and it might sound like a pipe dream, but I truly believe that Storyscript, over the course of the life of this company, will become the most popular programming language, far surpassing JavaScript in the industry. Maybe not quite up to where Excel is, but nonetheless. It’s more functional. But programming, I truly believe that Storyscript can be the most powerful programming language, because we’re not replacing any other language. We’re a new category of top-level programming. And so I really encourage the audience to think about this. I’ve used some bold terms, some bold concepts.
We’re evolving, we’re changing, we’re trying to pick out the things that we can focus on right now today—but then pick off the things later that we can’t, so we can get feedback. We can learn and we can grow with the new features of the industry, like server lists or Google Cloud. So I really encourage the audience to just think about it. Think like I did before I started Storyscript, where’s the industry going? What is the next big thing? Because it’s not what we have today. It’s something else. And I encourage them to provide that feedback to us, and see if they come up with something different. I’d love to hear that.
Darko [00:59:48] It’s very inspiring, forward looking. It also seems to be the right thing. So hopefully we will not have to wait for the next five or 10 years, but it will come sooner, to all of us. And I would invite people to also jump into your Slack, the slack channel that you have. That’s where I met you, when I discovered Storyscript. It’s a great place where you can follow the development and how things are going.
Steve [01:00:19] That link is at the bottom of our website. We’re looking to do events, so if you fall in love with the platform and really like what we’re building, we can help train you up on posting your own meet-ups and we can give you some swag, and some pizza, and coupons, whatever you want. We’re based in Amsterdam. And obviously from my accent you can tell I’m not from Amsterdam. I’m not Dutch, but I love the culture out here and I love the people out here. We’re building a team out here so if you’re looking to move, Amsterdam living is just second to none. And we love that we’re building a team. We’re hiring. We really just encourage communication.
I am honestly here and passionately here in the industry to provide this product to developers, and that is success for me. It’s to not be looking at how I can make the most money out of this, or giving developers fear that we’re looking to replace them. That’s not what we’re doing—we’re really saying let’s do this together. So I do encourage people to join our mission as well.
Darko [01:01:25] This was an amazing talk; very inspiring. Thank you so much for joining us. Good luck with Storyscript.
Steve [01:01:35] Thank you so much. I appreciate your time, and look forward to hearing from you.
Darko [01:01:38] Thank you. Bye bye.
