1. We are here at CraftConf 2015 in Budapest. I am sitting here with Sadek Drobi. Sadek, who are you?
I am Sadek Drobi. I work on software and I work at Zengularity. I co-created the Play framework, especially the Play 2 framework that uses Scala on top of Scala that became very popular. Then I decided together with the other co-creator of the Play framework to start a new project, a SaaS product for solving the CMS problem. It's called prismic.io and I have been working on that for the last two years.
2. You say you solved the CMS problem. There is no problem! It is solved, right?
We tried to solve that problem because we think that the way that we approached it in the past was constrained by what we needed back then and it was a long time ago when a web site used to be one page where you put your address. Developing a web site was a challenge and now it is not a challenge any more. The challenge is in managing content and that is why we say we are trying to solve the real content management problem and that is why we started prismic.io. It is not one problem, it’s a lot of problems and we keep thinking about how we can make it easier for content writers and developers to collaborate into making web sites – developers with their technology and content writers with our app so that they can manage content. Developers will use the API to fetch that content and display it in their technology of choice, basically.
Yes, they come directly from our experience with prismic.io. You know, we are a pretty small team. We try to think our way through. What we can do is software and we think that by thinking more about our software, we can make it cost less and we can make some very important problems in terms of scalability and performance disappear. So, basically, it is like magicians. They are people who know better physics than me and you and that is why they can make some tricks to impress us, to make things disappear, to make things move in some unusual way. Well, the most interesting property of software is for me is that it is soft – you can change it in all kinds of ways, right? It does not have a very constant physics and it does not have a lot of constraints either.
It has, of course, CPU and memory and even these are moving. That is why there is a huge space of opportunities you can exploit it for changing.... they call it the architecture, I call it the physics of your software, your product, your service. You change things around in the structure and suddenly, your problems disappear. So, pretty much like magic. So, I take an example in my talk: imagine we are living in a program right now, then if you get access to some exception in gravity, then you don’t need planes to fly. You kind of changed the rules and everyone can fly or some people can fly, because you changed the physics – physics is what rules everything and if you can change it, of course you can introduce problems, but you can also solve other problems. And this is basically the metaphor: you need to see more about the mechanics of your software, instead of thinking about tools and how you can plug these tools. That comes after! But first you should understand the mechanics of what you want to achieve.
Werner:
Give us one example or your first example.
OK. An example. Basically, what is prismic.io? It is a service that gives you a back-end where you manage your content and then an API which you will use for your web site. If you use prismic.io, your web site depends completely on our API. Basically, if our API goes down, your web site goes down too. And that is really a big problem, right? It needs to be extremely highly available. I mean, imagine – if our API goes down for whatever problem, there are so many web sites, all the web sites that use our platform will go down as well. We had to solve this problem. Not by putting some buzzwords on slides or on the web site, but we needed to solve the problems in the fundamentals, in the physics. It needs to become a simple guarantee, not a hard guarantee.
For instance, if people say “OK. We duplicate that and we put up more servers” – you are making the problem even more complex and as the problem gets more complex, it gets harder to give guarantees. You need to get the physics different, so that the problem becomes nothing – of course, scalable of course. You need to be able to say this, right? And that is what we like to do at prismic.io. We said “OK. There is a writing room – people try to collaborate and create new content and all that and there is the API.” Now, if we observe these two systems – imagine that you are looking at or just observing only the web site of the guy that is using prismic.io. You are looking at it. You do not observe anything else, not even your own thoughts. You are just observing this and you look at it and the web site is not changing. The web site is the same.
So, for you, the time of the web site is not changing, it is not ticking, it is not moving, whereas if you observe the writing room, the writing room is changing, there is new content inside, but no one published yet and that is why the other time is not changing. So, by just doing this, you notice that there are two universes, two different times – the time of the writing room and the time of the API and they are separate times. Basically, by observing that, you say “OK. Whenever I publish something in the writing room, I will change the time of the API” It means that I will push new content. But as long as I am not doing anything in the writing room, the system does not change and they are completely different systems. By just separating it in two systems, what happens as well is that, for instance, I use a different technology in my writing room than in the API. So, we use different data stores, different ways of storing data in the writing room than in the API. The API became a very simple thing – there is nothing there. There is only one Lucene index, so basically a folder containing files.
Every time we publish something from the writing room, we do a zip of a Lucene index, we make it a zip, we put it on S3 and then whenever it will get some request, it will be able to download it to unzip it and then to serve it to the users. Now, all you need on the API side is a JVM that is running and access to S3 and that is it – access to that file, not even to S3, access to that zip file. That is all you need- no database, not other connections. That is all you need. And that just guarantees that the API will be extremely highly available and it has very good characteristics for it and it can guarantee easily. There is not much to do to guarantee this. So, even if everything goes down, we need just a few JVMs and push these files on them. That is one of the examples of how changing physics can change completely the way you look at your problem.
Werner: You basically split the world into two universes.
Exactly. That is exactly what we did. Again, the API became a very simple problem. You don’t need a lot of engineering, no special database, nothing! Just a simple system. That is why it is easy to guarantee. You can say “Of course, I can give you whatever guarantees you want on that system. It is simple!” Whereas the other is more complex, but it does not need to have this kind of guarantees – it has a different guarantees and we never had to do that for maintenance, but if you need to do a big maintenance operation, bring down your database completely because you need to do something, you don’t care about that – the API is still up and running.
Werner: But during maintenance you cannot change the system.
Yes and we even did something for that, to make even maintenance and migration much easier, but that is another example of how you can change something, what I call the physics of the software, to make things behave differently and to make it much easier to guarantee things.
Werner: I am interested. Let’s give me another example.
The one that we were just talking about. Basically, you have different users using it, for instance, for different web sites. So, let’s say we have two or three users they use it each for their web site or their web app. Now, there is nothing shared between these repositories, right? They each have their own content. So this guy maybe updates his content twice a day, or every two hours and the other one just posts one blog post once a week and the other one does not connect that often – maybe once a month. The thing is that often, when you create systems, you put one huge database and everyone is inside. What this means is that you are keeping everyone’s data forever on your servers. So, you have a machine, a disk in there and you put everything in there. And that is a problem because this guy only gets to his data once a month, right? And you are keeping it around.
You are wasting your resources, basically. You are wasting your resources, but you do not have any other solution because, I guess, you are missing this thinking about the mechanics of the software. What you can do here is just to separate them into different databases. Now, this seems like a crazy idea, like to get a database per user. Well, that depends on the technology and that is a technology choice. You will think about that afterwards. But just think for a minute, if you separate this into different databases – what happens for the user that only uses it once a month? Well, while he is not using it, I could archive his database, remove it from the server and put it somewhere safe. Whenever he comes back, I can get it back, unzip it and let him access it. This means that my service can be much more efficient in using their space. It depends on how fast you can do this archiving thing and restoring – if you can do it really fast, then you can do it on a daily basis.
Whenever you come, I put your repository, I mount it and if you go for a long time enough, I can go ahead and remove it. Now, of course, you can put this also and relate them to others, maybe developers that are only testing the platform – you remove it fast; for users that are paying you keep it around, but the user does not even care about that. The effect is that the user comes back and he is seeing his repo in the way he saw it last time he accessed it. That is all he cares about. And he cares about the whole process being fast. If you can guarantee that this can happen in a second or two, he would not even notice it and this simple decision brought us so many advantages, a lot of advantages actually, more than you can imagine the first time you hear this kind of story because the first thing, we can store as much data as we want. Actually, today we can go to millions of repositories on one machine and there is no problem because people do not tend to update at the same time and even if they do, there is a way to manage that because you separated what is separate – they are decoupled and why couple them in one database. But there are other things that you can do – for instance, if you have a data migration to do, often data migration is like you freeze the world and you do the data migration that takes a day or something or an hour, and then you put users back. No, I can migrate for that user, whenever that is done I can migrate for the second user, for the third user and so on and so on. And everyone will only notice the time of his migration, they will not have to wait for the others and he might not event observe anything at all because whenever he accessed, maybe it has already migrated. So, you avoid this kind of monolithic, huge migrations by doing such a thing.
But there is even more than that. Today, what we do in our infrastructure is that we have different clusters. We have an experiment we call “The Experimental Cluster”. In general, we deploy like three-four times per day. We deploy a lot. We had different experimental clusters - and it is about the case in which we want to have a new functionality, for instance, and we want to test it before to see the impact on the other features, if it is a good feature and whether we have to improve it or anything like that. So, what we do, we deploy a new version of our software on that cluster and then we invite users to test this kind of functionality, this new functionality. Maybe they are interested, they want to help us to bring feedback, whatever it is. Then we keep bringing people into this cluster. Basically, we move that database, because it is separate, we move it into that cluster. By moving it, even if we had some enhancement on the data model, it does not matter because we migrate their repository into the new data model.
Then we test it and whenever we have enough people testing it, then we know almost for sure that it does not affect the production in a nasty way and then we can move it into the stable clusters. And that it is very interesting. It makes us like an environment where we can experiment with things without breaking everyone’s work. And that is, again, the same because we can separate these things, we can move people around. Some users don’t like to move their production repository, they can clone it. They take a clone of their repository and they just sit on the other. Now, a clone, if you separate databases in this way, a clone is just copying files, right? It is a very, very cheap operation. So, today some user may tell us “Can you clone my repository into the experimental cluster? I want to see what the impact is on there”. We clone it, they test it and when they are happy, they can move their repository or they can wait until we can put it in a stable environment. And that drastically improves the quality of our software, by doing taking these steps. And you see, all happened because you looked at the mechanics of your software and said “Well, there is an opportunity in there. Maybe I should use that opportunity to do something more interesting” This is another example of those kinds of things.
Werner: You mentioned something about REST.
Yes, but not now. When we were talking offline and in my talk too.
4. In the talk, yes. So, everybody likes REST. Who does it right?
I tend to see that. Most people do it wrong. It is obvious to see it, actually. I mean, who cares about wrong and right? There is an opportunity in REST for the API that people are missing. I do not care about what it wrong and right, but there is something interesting about the web way of doing a REST API. I mean it is very simple to understand. That is an amazing thing that people tend not to understand it even if it is really, really simple to understand. A RESTful API is a web site. Some people call it an ugly web site because you do not have a CSS and all the styles, though we do it at prismic.io – we provide even a version with nice CSS and all.
Your API is one end point. Basically, it is the URL or the web site. So, it is the URL of the service. Now, whenever you call that, even programmatically – you can call it through the web, or you can call it programmatically – it will return a page, let’s say, a document. It could be an HTML, it could be JSON, whatever it is. This document will tell you what you can do from there. It tells you something like: “Here, to get this kind of documents, you should do a GET on this URL, with these headers. If you want to submit something, for instance, then you use a POST on this URL with these parameters and so on and so forth. So, the first time you call it, it gives you a result and then you analyze that result to see what you can do from there and then do the action and then we get you onto another result and so on and so forth. Why is this interesting? Because it gives you so much flexibility. No one has to save URLs or use concrete URLs.
You decide where the URL goes. So, the only thing they have to know about is the very first URL, the URL of the service. And even this can be configurable, you can put it in a config file. And the interesting thing with this is that if you suddenly want to introduce some CDN, you do not care, because the first URL, when you call it, it will give you all the URLs through the CDN. That is transparent for you. You do not care about the URL because your program will just take it and use, exactly as in the web site. You don’t care when you click on the link what the website is, you just click and it brings you where you want. So it is just the web way, the simple web way. But there are other properties where you can change URLs in that way. So, we are at some kind of version of the API, someone publishes something. When you get the /API, the first URL, it gives you a document.
All these URLs – we put the version number inside the URLs. Now, if someone publishes a new version, all these version numbers change. You don’t see them because your program does not care about them, but this means that we invalidate the cache in a very efficient way. So, this means that our API has a “cache forever” semantics so you can cache it as long as you want, but whenever there is a change, you get it right away. You do not have to wait until the cache invalidates, because the URL changes and it happens automatically, because the ref changes inside the URL and it is another source and you will be able to get it and cache it again. That is simply by using a RESTful API. It gives you so many advantages and flexibility, if you want to move your servers around, if you want to do some load balancing, all these things – they happen magically because no one is caring about the URLs. That is how we use the RESTful API.
5. That is lots of interesting design experiences from the working of prismic. io. Are there any more?
I suppose that when you try to get into some problem and you try to think about it from scratch, any product would go into this kind of things. Today, in this conference, you listened to Netflix or others. They had to face this kind of things. They do not have a choice. They want to stream all around the world so they have to do things differently. They want to bring in new things, they have to think about things differently. You can’t do it any other way. And every day working in prismic.io is about solving these things.
So, I can think of other examples, but they are all within the same thinking: try to look at your problem in a different way, try to understand the mechanics and then move things around to make things happen the way that you want them to happen, right? But we also did a lot on the user side. For instance, our focus was to make it easier for publishers. The thing I said - to make content management easier – which means there are so many things. Today, everyone agrees that content management is a hell. Whenever you want to do any content management, there is a lot of suffering. So, what we wanted to do was to solve the real problem and one of the problems – I talked to a lot of people who use content management systems and there is a problem of stress whenever you publish something.
You are very tense, because you do not know what happened, you do not want to break the web site and it is an important moment and it is really a stressful moment. Why should this be a stressful moment? Because you can’t test it before. So, by just organizing your content in prismic.io, we use immutable documents, so basically, anytime you do some change it is a new document and by doing that, we can have different versions in the same time with the API that do not affect each other. So basically you have the public version – we call it the live version – but you can have different releases – we call them releases, more or less the same as branches or pull requests in Git. And these things that we call releases, they are exactly like the live API.
All you need is to change one parameter in your query when you are using the API to get this release, rather than getting the live one. This means that you can prepare a release with maybe ten or hundreds of document changes and you can test it in your web site. Because if the developer used the API, they can change only one parameter to see another version of the web site and that does not impact anyone. So, basically, the content writer or the publisher can prepare a release with as many changes as they want, they can preview it in the web site and this is exactly how it would look like, if you publish. And why isn’t the publishing dangerous anymore? Because there is no action in there. All that we do is to point to the new reference.
Actually, behind the scenes, all that happens is that we are changing one little string and that is it. You have exactly what you tested. So, there is no surprise, right? And again, this is a functionality and the user will be happy to get this kind of functionality. How do we solve it? By using architecture, by using this kind of magic, saying “OK. If publishing is a problem, let’s make publishing easy! Even technically easy” That is how we win this thing. That is one of the example of things, like using immutable documents and a structure that looks very much like immutable data structures.
Werner: OK. Interesting experiences from working on interesting products.
Yes. Always. I used to do a lot of consulting before and consulting is good, but you do not live enough with the product. That is what I was missing. I wanted to live enough, start at the beginning and live enough to see problems happening and to say “How can we solve that? We should solve that. I cannot just quit. I have to solve these problems” And I guess the most important thing about our profession is that you need to think and thinking is really interesting. Seeing different things: infrastructure, design, functionalities and if you have the full vision of everything, then you can change things together. You can change the architecture so that it can be able to accept new functionalities that you are thinking about so that everything is in coherence, because at this size of the product and of the team, you can still do this kind of decisions, in fact, a lot of things at the same time. Of course, we are going to lose that at some point, when we become a much bigger team, but today, and it is very surprising whenever I tell it to someone, we are only seven people in the team whereas exactly for the same product, with much fewer users, they have 200 or 300 people working on that. Again, we like this and we like thinking about problems and that is why I like working for a product.
6. To wrap up, I think the product is written in Scala?
There is a lot of Scala, there is a lot of Javascript as well and we use different technologies in data stores – MongoDB, Redis, Lucene, we use BookKeeper, ZooKeeper, Amazon S3, CloudFront – these are the technologies we use.
Werner: So, you are still happy with Scala.
Yes. Anyway, the first thing when I wrote the Play framework, I was one of the first people, me and Guillaume, we wrote the Play framework and I wrote it for Scala and I guess, I still think it was a good decision. There are always debates about programming languages and sincerely, I do not care about this kind of debate because, you know, lately I have been spending a lot of time writing PHP and I feel it is very interesting as well. I mean the experience you can discover, you know. It is a way you say “OK.
I have these tools and I have to use them and have to do good stuff with them.” Then you try to think your way through. I mean, it is always about having tools and saying what you can do with that. Imagine you have some plumbing problems and all the tools available, you have some tools and you need to find your way through it. We are humans and that is what we excel at is thinking and using the tools we have to do stuff.
I do not care about the language debate, but I think that for a good developer Scala is very expressive and gives you a lot of things. So, it gives you the opportunity to write things in a more concise way, in the way you imagine to modularize them, in a way to model them, in a way that makes sense for you because they have enough modeling tools, including functions and objects and traits and a lot of other things and you know you can mix things to make something that looks almost exactly the way you want it to look like. That is exactly why I like Scala, even if Scala is a big language compared to other languages and, you know, sometimes, with the learning curve, you pay some price because you need quite a long time in the beginning to really grasp everything about Scala.
Then, whenever you are there, you say “OK. I cannot use anything else because they have fewer tools” But, you know, it is always an exercise. How can you express yourself in a different language? Now, Lisp is very, very expressive and extremely simple and modular. So, the most important thing is modularity and you have to cheat in the language to find the modularity. In Javascript, what they like to do is to use functions for modules, right? So, you call a function, inside a function there are other functions and so on and so forth. That is how you cheat in the language to get your modularity tools. So, that does not exactly matter, but I still have a good time writing code in Scala. It helps me think.
7. I am excited to use prismic.io now. Where can I go to get it?
You go to the web site and there is one of the things that we had is that prismic.io is, as I told you, the back end and an API. That’s it! You do not get a web site, you have to build a web site. You take your technology – Javascript, Scala, Python or even any other technology or native app, anything – and use that API and do your stuff. That is a good part about it. It’s extremely flexible. That is why all our clients choose prismic.io, one of the main reasons for choosing it being that they want fresh designs, new designs, they want new technology and they are bored of this and they can’t bear anymore the old technology used in CMSs and they want to have that choice.
That is why the design tends to be really interesting. I always liked browsing the clients that we know to see, browsing their web sites. They are really using the latest technologies in the browser for that. But, you still have to invest some time in all that, you have to develop your web site from scratch and “from scratch” scares everyone. Not because they are unable to do it. It scares me too. I mean, I had to do a web site. I play badminton and I had to do it for our badminton club. I wanted to experiment with it. Wow, I mean there are so many decisions to take and I am a lazy person, you know. I was like “Wow, this will take me like a week or so to get into it!” So, in order to break your content into different masks and then you start developing from scratch, you write Javascript and HTML and all of that. It is a lot of work that you do not exactly want to do every time, right?
So, that is why what we are coming with – we are going to release it soon – is what we call a “web site startup”. A web site startup is like, for instance Bootstrap is to CSS. It gets you something that is already configured, pretty flexible – it has a flexible layout, with columns and so on and so forth and you can start with that and change it any way you want. It is open source, so you can change it. It allows you not to start from scratch. It gives you an example of how you can use prismic.io fully, with all integrations needed, but also, it gives you some way to kind of not start from scratch, to understand things and to go modify; modifying is much easier, even if you end up with a completely different result, starting with something pre-existing is still much easier. So that is what we are going to release very soon. Actually, it contains a new feature: we found what we needed and then recently developed it and there are users already asking for it. So we are releasing a new feature for that, for this web site startup thing, and you know, we thought that people need this kind of things, but we were not sure and then lately, after we developed it, people are asking for it and yet we did not announce it. So people thought about these things.
It is often a problem when you – basically, imagine a developer who worked on a web site and then the developer goes to work on something else and then the content writer wants to create a new page, for instance for an event, for a conference, for a mailing list, for anything. You always need to create new pages. It is annoying to ask the developer all the time to recreate the new page. In the process it becomes much less lightweight. Sometimes the publishers like to create their own pages. Of course, they want to respect the entire theme, the entire design of the web site, but they also need to have this flexibility because this is what marketing is about. You take opportunity and you say “OK. There is an opportunity. I should make a page about that and start talking about it, tweeting about it and all these kinds of things”. Now, what we came up with is a new content type, we call it the “dynamic zone” or the “content slices”. With content slices you would say “Here is the zone and inside this zone you can use one of these five types and these custom types” So basically, in this zone, I could give my publisher a choice of slides, feature list, question/answer, FAQ for example, quotes and so on and so forth. I can provide as many choices I want for my content publishers and they are just content. So for instance, the slide custom type will contain the title, the image of the slide and the bottom title. And in the feature list something similar and so on and so forth.
Now, this is only content, right? In the other side, what the developer does is he will get whatever the content writer decided to put in this zone and can present it in the way they want. So, he will put style on top of these content slices. He will say “The slides will be full screen, with the title here” and so on. This gives the publisher a nice custom framework – it is for the web site, for this client, for this web site. Of components, let’s call them components or layout slices, whatever you want to call them, so that they can create other web pages out of them. So, I have an event, I put some slides, some feature list and some frequently asked questions and another block and that is it: I have my page, styled in the way that the web site is styled, yet it is a custom page, right? And this kind of dynamism, when the developer and the designer already define some kind of layout, but they leave it sort of flexible so that you can create custom pages. And all this, together with the web site startup will help people to start with prismic.io much faster. If you have 5 minutes or 30 minutes, you will be able to do it. For instance, you are at lunch time, you have five minutes, you can download the whole thing and start playing with it.
A web site startup is an example theme with some slices already integrated so you can play with it, create your own pages and you can even change the whole style, the whole layout, you can do whatever you want. Yet, you can start from something that allows you to do enough at first. It can make you fill most of your web site and maybe the rest you can ask a developer or do it yourself or whatever it is. This is what we are trying to solve now: making the whole thing much more dynamic rather than extremely dependent on a developer. I am viewing now prismic.io as a framework for doing CMS or a platform for doing CMS. You would do your own CMS anyway, right? You configure your thing and it becomes your custom CMS. I mean, not in a complex way, but rather in a very simple way.
Werner: So there are a lot great features coming up. I guess, by the time this interview is out, all of this will be available.
I guess they will be available. We are getting them out very soon.
Werner: I think we will all check out prismic.io.
I hope so and do not hesitate if you have any questions.
Werner: Well, thank you, Sadek.
Thank you very much for having me, Werner.