- The document discusses different approaches to server infrastructure - the mobile/product-focused Parse approach, the Heroku "server is software" approach, and the AWS "climb the server mountain" approach. - With Parse, the focus is on providing backend services for mobile apps through an easy-to-use platform. Heroku emphasizes treating the server as software to be developed. AWS puts the user directly in contact with infrastructure components. - Each approach has tradeoffs in terms of learning curve, costs, flexibility, and how long they are suitable before needing to transition to another platform to handle more complex needs. Managing servers requires developing new skills around concepts like storage, security, deployment and more.

1. Server’s variations BSW2015
lcerveau@nephorider.com lcerveau@mmyneta.com
laurent@zen.ly

2. • 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)

3. • 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

4. Many concepts
API
Storage
Data
Security Cache
Domain Name
Deployment
Push
Analytics
Load
Asynchronous

5. 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

6. 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

7. 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

8. 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

9. The product/mobile/toptobottom approach

10. 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)

12. 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

13. 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….)

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

15. 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

16. 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 ?

17. The “server is software” approach

18. 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

19. 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)

21. 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)

22. 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

23. 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

24. AWS : “Be brave and climb the
server mountain”

25. 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”

27. 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…)

28. 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”

29. 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

30. 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

31. Get an overview: Nephorider
Dashboard, hardware, network dataviz: www.nephorider.com

32. 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)

33. Thank You!