Service ready for production? Well, at least this was the original title of my talk. But I got so bored while preparing the talk, that I was afraid that you might all fall asleep during this "enterprisey" presentation. So instead of bombarding you with all the software as a service jargon that I had prepared, I'm going to tell you two and a half stories. They still have to do with Backends as a Service, don't worry.
idea. That's not unusual. Many people have a lot of ideas how to improve their or other lives with an app, but most people don't have the tools to make the ideas come true. At that time, I used to be a product manager. I knew a lot about how to make a concept for a product. And I decided to act on my idea. So climbed down from the lighthouse overlooking the sea of possible ideas and paths and got down to business. Image Credit: Lighthouse (Moonrise Kingdom) http://www.themovingarts.com/moonrisekingdomtheandersonformula/
examples for the rest of my talk. So prepare to get wet. So what do you do, to track down one path in the wast ocean of possibilites: I used the tools I knew as product manager and started creating wireframes, flowcharts & clickdummies. It was all great and I was happily sailing on my path to my own app. But of course it still wasn't an app, it was a concrete concept. If I wanted to see if the concept could work, I needed to give it to people, let them play around with it. To create a real app, I needed to dive deeper in. Image Credit: Pirate boat (Monkey Island 2) http://mixnmojo.com/mojo08/media/galleries/MonkeyIsland2LeChucksRevengeSpecialEditionScreenshots
water and started snorkeling. If you jump from the ship into the water, the tools you need to survive are different. I learned ObjectiveC, learned to work with XCode, Interface Builder and in the end of a long process of learning, desperation and hope, I had an app! It was working! Well, almost. You know, of course my idea wasn't trivial, it should be a community around learning, that meant, I needed to have user accounts and be able to share data between users. I needed a backend for my app. So once again, I needed to dive deeper in. Image Credit: Madagascar 3 http://www.highdefdiscnews.com/madagascar3europesmostwantedbluray3dreview/
learned Objective C, I don't want to dive deeper, it's dark down there and evil sea creatures are lurking around" But unfortunately, to reach the goal I had set me, I really needed a Backend. And again, I tried to gather all my courage and prepared myself to dive deeper in. But this time, I wanted to make sure, that there wasn't a next step of diving deeper. Image Credit: Divers (Life Aquatic) http://www.thepoularde.com/2010/08/tenken.html
abyss of server and database hosting and administration. No no no, I wasn't going to go there. I already seemed to have lost track of my app idea, by diving down so deep. I wasn't going to learn how to navigate a submarine now. Image credit: Submarine (Abyss) http://www.incine.fr/film/abyss
CouchDB: • NoSQL database • HTTP Rest API • add business logic through update functions and replication between databases There were also 2 services that provided CouchDB hosting. And for the cherry on top of the cake: there was an iOS version for storing objects first locally, then synching the data back to the server, when there was an internet connection. I therefore even had an offline mode, perfect!
you can do with CouchDB in this talk. So let's just say, CouchDB was good fit, but I needed to bend CouchDB to my will a lot, to make it work as my only backend. And I wished someone or something would take care of writing the code for creating user accounts and user databases, changing passwords and whatever. It was possible, but it just took a lot of time away from me, where I couldn't work on the unique aspects of my app. Well, this wraps up, the first part of my journey. In the end, I had a fully working app, I had learned tons of things and I was moderately satisfied with the progress I've made. The app wasn't a success, though. Maybe because • the idea and the concept weren't good enough, • maybe because it took me too much time, • maybe I was using the wrong tools and couldn't operate them well enough, • maybe I sucked at marketing. Probably it was a combination of all of these things.
to make a short break to show you this super academic slide of the maritime ecosystem of Everything as a Service. In this example each level in the ocean, stands for a different set of skills and tools, you need in order to master that level. Fortunately for us, there are services that provide the expertise prepackaged for you, so you can stay on a higher level on your journey without getting lost in the abyss of the ocean.
with virtual machines, servers, storage, load balancers and networks. You surely CAN setup and administrate that all by yourself. But I'm pretty sure that you don't want to. If you don't want to spend time doing it yourself, you either hire an admin or rely on Infrastructure as a Service. Services like Amazon S3 and EC2 and Rackspace are located in this area. Infrastructure as a Service allows you to operate in the middle deep sea, without having to dive all the way to the ground.
to do with application development and deployment, execution runtime, databases, web servers and so on. Services that provide you development environments for PHP, Ruby, Java, Node.js and databases like CouchDB, MongoDB, you name it. They are all located here. These services are called platform as a service. Both Infrastructure as a Service and Platform as a Service are used a lot in production today and although there will always be some people who claim that everything is better when exactly customized to your needs, there are not many app developers out there, who would prefer to do that on their own. What these services offer, is in almost all cases sufficient and let's you dive around in shallow water without too much pain.
that level, where your app backend is located, there are things that are always very similar in most apps. This is the repetitive backend stuff. It includes: Image Credit: Fish Swarm http://urbanfragment.wordpress.com/category/other/
not too familiar with the underlying deeper level, you might think: how hard can it be? I write that in a few lines of code. I thought so too, but if you are not a diver, you don't know all the creatures you have to fight and all the problems that can occur during your journey and how to stay safe. Take storing passwords for example. How many people here know how to safely store a password? You can't do that in just a few lines of code. A lot of even big services leaked user passwords in the last years, because the passwords where not salted and encrypted properly. You should know what you are doing and especially when it comes to security. And even if you know what you are doing, it will take a lot of time to write and test the code properly. Time that is then missing in your app development.
providers like Parse, Kinvey, Firebase, BaasBox, Hoodie, ... got into existance. The question is: are we there yet? Can you use these services in production without sacrificing too much of the flexibility you have when writing your own backend?
journey. Last year, I was working in the Mobile Team at Project A Ventures, a startup incubator here in Berlin. Our goal at that time was, to start a process of rapid protopying of app ideas. To begin with, we started out with two app ideas, we wanted to test and bring to the market very quickly. Given the setup of the team at that time, we decided to develop one app iOS first and the other one Android first.
backend developers for PHP, Java and Node.js in house, but they were mostly booked for other projects. We could have booked a developer for a few days, but then we would have to have a clear specification of what we needed the backend to do. Which we hadn't because knowing exactly what you are going to build and what you are going to need for it, isn't really a part of rapid prototyping. We needed a backend that we could adapt quickly in many iterations to our changing needs. That's when we decided to use a Backend as a Service. As we were all busy with app development and short of time, we didn't really make a real assessment of what Backend as a Service providers there are and which one would be the best fit for us. We just picked Parse, because it looked very easy to setup, was the most popular, we didn't hear any bad things about it so far and backend functions could be written in Javascript, a language we all didn't know too well, but thought we could deal with. So it was settled. Image Credit: Paper boats http://www.wallpapersshop.net/wallpaper/cardboardrobotpaperboats/
of cake, just a few clicks on the website, install the SDK and you are ready to go! We were convinced we made a great decision. We focused working on our apps and Parse handled the rest. There was a bit of business logic we needed in the backend, no problem, we just wrote a few Cloud Code functions. (Cloud code is how Parse calls its ability to extend the given functionality through Javascript functions) All was well. Until it wasn't. Our first problems began after a few weeks and lasted and grew a lot when we went live with the first app. Image Credit: Kissing fish http://www.eakwarium.com/guramicalujacy.html
stay with the love a little bit longer and see what are the top reasons for choosing a Backend as a Service, instead of writing the backend yourself or let someone else write it. Image Credit: Starfish on Beach http://www.allwallpapers.net/wallpaper/heartbeachstarfish/
with well tested, secure code, written by an expert. At least it should be that way. At least in most cases the quality of the code is probably much better than something an app developer hacks together in a few hours.
have the knowledge to write your own backend, you can hire a backend developer. Which of course costs money. Most Backends as a Service provider do cost money at some time, but at least in the development phase of your app, it's mostly free.
takes time. Always more time than you think. In many cases that's time where you are reinventing the wheel, because most of that code has been written before.
am an app developer and I'm good at it. I also know that I need to focus on the important things to make a good app. If I have to worry all the time about API access tokens, secure password storing or setting up a service to send push notifications, I can't focus on the app itself. I am distracted by problems almost all apps have.
that make my app special. Now back to our Parse experience and the time our love went cold. For that, I need to explain Parse a little bit more. The Parse backend is based upon MongoDB and Node.js. You might think about these technologies what you want, I know there are many people that are not exactly fans. But they are still powerful tools in the hands of skilled developers. Now Parse doesn't let you handle these powerful tools by yourself. It doesn't even make it transparent what the underlying technologies are. Parse puts MongoDB and Node.js in a box and provides you with a slightly different and dumbed down interface.
something goes wrong. For one of the apps, we needed to connect to the Amazon Simple Notification Service, to get notified, when a video was processed. If you ever had to connect to an Amazon Web Service, you probably know that authentication is a total pain, if you have to do it yourself. Thank god, there are SDKs for all the major platforms which let's you easily connect to Amazon. Even one for Node.js. Parse is based on Node.js, so we should be able to use it, right? Well, the documentation simply tells you, that some Node.js modules might work with Parse, some might not. Unfortunately for us, the Amazon Node.js module was one of the many ones, that didn't work with Parse. By using Parse and saving a lot of time in the beginning of the development, we were now loosing a lot of time by having to reinvent the wheel and writing code from scratch, that was already out there, working and tested, but we couldn't use it. Because this was all too much for our basic Javascript skills, we got help. A Node.js developer for the rescue!
just ask them for help with Parse. They are SO gonna love it! Here's how our first interactions were like: • Ok, let's get to work. How do I set this up locally? Where is the local development enviroment? • Ehm, there isn't one. We always need to deploy our changes directly to the server. • WHAT?
the logs? Where can I see what I am logging see errors? • Oh, yes, on the website you can see some logs. It is unfortunately limited, you can only see about the last 50 lines or something like that. Also, we are not sure if it does display the correct node.js errors, it might eat some of them and just display a general error. • WHAT? It was like locking away all the powerful tools a craftsman uses and knows how to handle and just give them a hammer to build the complete roof for your house. In the end, we managed to get it working, but it defintely wasn't easy and we lost a lot of time and nerves. Image Credit: Facepalm Polar Bear http://www.winecellarcobwebs.com/2014_02_01_archive.html
want to know more about them find me later and I'd be happy to rant more. To be fair, some of the issues we had, were addressed by later new releases of Parse. But from my point of the view, the main problem here, is that Parse is a Silo. You can swim around happy in your fish bowl, when your requirements don't exceed what Parse offers you.
your fish bowl, the way to the rest of the ocean is blocked or at least very hard to reach. And it's not easy to just switch to another Backend or Backend as a Service: your classes are subclasses of Parse classes, the data export function is clumsy, we are definitely not talking about a few days for a switch here. So, that was the second part of the journey, let's move on and have a look at some of the other Backend as a Service providers. Image Credit: Aquarium http://www.heimhelden.de/aquariumimurlaub
lot about Parse. So what else do you need to know. It's basically the swiss army knife of backends for indie developers. It provides you with a lot of things that exceed the basic backend needs: push notifications, hosting websites, Facebook and Twitter login and signup, basic analytics and SDKs for iOS, Android, .Net, Javascript and Unity. Parse is owned by Facebook. Make of that, whatever you want. And your backend is necessarily hosted by Parse. No way out.
needs rather than indie developers. One big difference to Parse, is the Dedicated Kinvey option. Dedicated Kinvey means, you don't need to store your data on servers that Kinvey provides. You can let Kinvey operate and deploy the backend on your dedicated servers. Looking into Kinvey might be a good idea, if you have special requirements of where you data can be legally stored or have special concerns for security.
into a silo. It's fully Open Source and you can deploy your Backend anywhere you want. The backend is based on Java, I'm not sure however what kind of database is used. But if Java is one of your preferred tech stacks, you might want to look closer into BaasBox. From what I can tell, it's still in an earlier development stage, but it's definitely one to look out for.
extremely biased here, because I wrote the iOS SDK for Hoodie. But nonetheless everything I say about it, is true. And yes, I can see totally the irony, that I said in the beginning, that I just wanted to work on my app and not even care about the backend, and now I am working on a Backend as a Service? Here's how that came along. You remember my first attempt at a Backend was CouchDB? A good choice for storing and synching data, but it was a bit harder to add business logic. People recommended me then, that I should use Node.js for the business logic and let CouchDB just handle the data storage and synching. But how to set that up exceeded my knowledge at that time. Ok, not only at that time, I still wouldn't know how to do that properly. I also didn't have time and money anymore. So I stopped the development there.
with Parse, there were some web developers, who had basically the same problems as I had. And they started Hoodie for web apps based on Dreamcode. Dreamcode means: they first created the API of their dreams: a single line of code for creating a user account, a single of code for storing an object and so on. And they also found people who could make the dreamcode come true. They created Hoodie with all the cool stuff: • It's Open Source • You can deploy it anywhere • It’s #offlinefirst, which means, your data is stored locally first and synched on demand to the server • It's extendable through a plugin system • It won't make your Node.js developer cry, if you need help, because it doesn't cover what it is based on After I heard about Hoodie, I was totally excited! This was exactly what I needed and wanted all the time! But it was for web apps only. I was like: Why is no one porting this to iOS? Hello?! Anyone? Someone should do that right know! Oh right, I am an iOS developer, if I wanted it, why am I not doing it myself? So that's what I did or at least started. The iOS port is still in an early stage, but doesn't have to stay there, especially if some of you might want to contribute. You are hereby happily invited. If you want to know more about Hood.ie or want to work on a hack with Hoodie on Friday, talk to me later. I'll be around all three days.
not the complete list, there are many more fish in the sea. Here are some others I found. There are some, that I didn't look further into, because they are more like a Plattform as a Service with just some business logic added to it, Azure for example. Others are focussing on a special category like games. So you definitely have a lot of choices when it comes to Backends as a Service, but the key question remains:
to that. We are definitely on our way. If you are using a Backend as a Service to quickly prototype an idea, I would says: yes. At least given that you don't have too fancy requirements. If you want to use it in production, it depends. For some apps, it might be good enough already. For many others, if you choose a Service that puts you into a silo, it won't be enough. The question for you would then be:
outgrow the given functionality? You would then only be limited by the tech stack the backend chooses for you. Or are the benefits of the supported functionality not enough to sacrifice free tech stack choice. That's only a question you can answer. If you ask me: No, we are not there yet. But what we have, makes my life as an app developer definitely more easy already and I can see that the future is even brighter.
kaalita
akexorcist
sonatard
techiro
ryosukeigarashi
abemii
hogelog
takumiogawa
nobutomurata
mizdra
lycorp_recruit_jp
salaboy
lmi
holman
sugarenia
brad_frost
bluesmoon
tammyeverts
mraible
sachag
paigeccino
geoffreycrofte
addyosmani
marcduiker
denniskardys
