Server’s variations BSW2015

lcerveau@nephorider.com lcerveau@mmyneta.com

laurent@zen.ly

• You are more a product/UI/mobile/Frontend guy

• The further server reference you have is the idea of API

• You have (initially) no desire or time to learn server stuff

• After all it should just be a commodity…

Common scenario (personal experience)

• Your servers and infra will also give you nightmares

• Problem will have an immediate impact

• You will have the feeling to be able to do nothing

• You will not understand any word from your server guys

• All the hype about Cloud making it easy will look like a joke.

In real life

Many concepts

API

Storage

Data

Security Cache

Domain Name

Deployment

Push

Analytics

Load

Asynchronous

Organizing all this• There is always this “top to bottom”, “bottom to

top” idea. Here we are more on a spider web

• Each element has the DNA complexity of the whole: compute , structured storage, object storage, network & security, virtualization & containers, DNS + more elaborated

• Big challenge is “when to decide” that one does not want to deal with a complexity. Because of a certain tendency to accept an understood complexity

Human resource• Impact is not only on development but also on a

team structure. How many “roles” to hire? At which cost ?

• I think you can not ignore the world “Fullstack” or “Devops”. Question is “what does it encompass” ? What part of trendy wording is here? But certainly boundaries are less fixed and jobs are changing (in particular with the cloud)

• What is good at a point in time may not be good in another…as usual

Variations

Facebook Parse : the mobile/product/toptobottom approach

Heroku : the “server is first software” approach

AWS : the “Be brave and climb the cloud server mountain” approach

This has no pretention of being exhaustive

I have no intention to

• Debate about the best technology/language

• I repeat again :”In absolute no approach is better than an other”

• Provide precise sample on how to use those technology. Just some important points

The product/mobile/toptobottom approach

A little bit of context

• Parse : part of Facebook. Available at parse.com (April 25, 2013 according to Wikipedia)

• Progressive pricing . Start Free pay as you grow (request count, used storage…). Makes you understand some parameters of cost on the Cloud

• If one had to find a competitor for me it would be Apple’s CloudKit (although less developed)

The backend of your mobile app• Interesting approach as they put Analytics from

the beginning (Core/Push/Analytics on top of the app bar). Measuring your app customer performance is _important_

• Deals with an important topic : notifications. This is something very often underestimated

• Commodities allows you to have a “I learn from mobile approach” : e.g auto class creation

Full Product approach

Technically• Offer template/starting point for many platforms :

mobile, web, but also some “alternative SDK” like Xamarin (Mono C# technology) and Unity

• Backend is very much in the MongoDB/Javascript tradition but it is not necessary to know it at first. Webhooks allows to integrate with your own server/language

• Creation of data comes with “good habits” : in what should be in a server entity (ACL, creation date….)

Technically(2)

• Also presents concepts in a way that makes them “learnable” : data, long time background process….

Miscellaneous• Likely no worry about “how long will it be there” (hey

this is Facebook!)

• Have “decently big names” on their user home page

• As part of learning curve : couple of hours or days to get simplest thing, one week already gets you far.

• You can learn from both sides : client and server. That is if you know only client coding you can at first do all here

Where/When do I stop?• The commodity of the beginning can prevents you from

from learning the real problems : e.g auto created class

• When does it start to take much more time to integrate your own server part (with webhook)? It is nice because your own code can focus on your own value, but at a time it can be a time eater

• IMHO 2 parts are “too hidden” : infrastructure and deployment issues, Organization of a big size project. Of course somewhere this is the goal of hiding this

• I never had to “scale” with it. Easy? How much ?

The “server is software” approach

A little bit of context

• One of the older PaaS (platform as a service), born in 2007 acquired in 2010 by Salesforce

• IMHO went to fame because it was in sync with its time : Ruby On Rails, SQL (PostgreSQL) and Git integration

• Somewhere the older version of Parse at a time where doing web ships in Rails was the trend

• Did evolve with newer technology

Money (That’s what I want)

• IMHO a less friendly cost model both at the start and as long run. Free seems not possible with production (Must sleep 6 hours in a 24 hours period)

• Dyno (basic unit) prices range from 25$ a month to 500$. Compare to a small runAWS EC2 instance…so maybe not for the long term

• Maybe a good way to go towards AWS (in terms of features and pricing)

Technical approach

• A small step toward more playing with machines : heroku is a command line tool, platform offers some options like choice of regions, operational metrics

• Somewhere this is just Amazon hidden: you can use other components (like a DB on RDS)

• Proposes top class integration for some parts (New Relics)

Development process

• This part stays like any development : if you do Rails, you’ll need to learn it, use tool like rake (through heroku tools).It hides the idea of a web server versus application server and infra setup

• Makes a good use of common tools (e.g learn Git through heroku) good habits of using them

• A little bit longer learning curve than with Parse IMHO

Where/When do I stop?

• The cost. You scale, you better go to AWS directly

• The flexibility : at one point you’ll get closer to the core and want to separate functions through machines….although more understanding on your scaling

• The moment you realize only your application server stays on Heroku

AWS : “Be brave and climb the server mountain”

AWS?• Still major player in the cloud today. Certainly the

one with the most experience and the most services

• But this should not hide the fact that there are other services : Azure, GCE but also players with a particular approach : Outscale in France, Exoscale in Switzerland…

• Something that can be useful : they are very startup friendly (AWS Activate). Not a “Start free if you do nothing” but “Start free for a period of time/amount of money and become real”

First encounter• Likely you’ll get lost! Many dots to connect. Find

your global overview

• Wizard exists that help you do simple tasks but in the longer run you may find that they let a lot of trash behind

• Some wording can be confusing : e.g “Security Groups are Firewalls”

• In general very good ecosystem that can be very helpful (AWSome days conferences, AWSUG…)

Philosophy• AWS offers you in a “virtual way” everything that

used to be real.

• So it puts you directly into the core of learning what is infrastructure : sizing, cost, security, network, a certain level of monitoring (Cloudwatch), choice of Operating System

• AWS is at first infrastructure (IaaS) : so once you get your servers/VM over there you have to do another part : for example set up a web server with SSL certificate, managing user and groups, deciding where to install elements, automatic deployment and versioning. That is the “other software part”

Learning curve• If you start from virtually nothing, then you

usually have preconceived ideas about how things get organized (e.g : hardware connected view of things)

• Then you realize the complex concepts are important design elements : case of VPC. Not only security, but it provides a logical and functional organization. Stop thinking “like a software guy”

• You’ll get use to pricing with time: t2.micro is around 10$ a month

Learning curve (2)• Still there are some way of thinking to learn : find

RDS Security groups in EC2, is a volume having an attachment to an instance or an instance a connected volume, between ACL and Route table when none is specified for a subnet what comes as default (if something comes)

• Many technologies are presents, sometimes with an AWS “naming flavor”, sometimes not. For example Elasticache is Redis or Memcache,

• Some parts may become mandatory : e.g VPC, IAM

Get an overview: Nephorider

Dashboard, hardware, network dataviz: www.nephorider.com

Where does it stop• The boundaries are what AWS proposes.. and

your programming skills (yes you can program all this)

• I personally do not use all, and you can not apply one module to all : SES versus a service like Mailchimp. For me this is not playing in the same category

• Definitely a learning curve : each new technology gets easier to get AWS mindset,This is a long term investment: the price you’ll pay is the defendant of your learning curve (e.g autoscaling)

Thank You!