SlideShare a Scribd company logo

Server’s variations bsw2015

•
•
Laurent Cerveau
Laurent Cerveau

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

Related slideshows

Modern web dev_taxonomy
Modern web dev_taxonomyModern web dev_taxonomy
Modern web dev_taxonomy
 
Untangling - fall2017 - week 7
Untangling - fall2017 - week 7Untangling - fall2017 - week 7
Untangling - fall2017 - week 7
 
Georgia Tech cse6242 - Intro to Deep Learning and DL4J
Georgia Tech cse6242 - Intro to Deep Learning and DL4JGeorgia Tech cse6242 - Intro to Deep Learning and DL4J
Georgia Tech cse6242 - Intro to Deep Learning and DL4J
 
1 of 33
Download to read offline
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)
Server’s variations bsw2015
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)
Server’s variations bsw2015
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”
Server’s variations bsw2015
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!

More Related Content

Server’s variations bsw2015

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