Profile

Cover photo
Peter Magnusson
Works at Snapchat
2,157 followers
AboutPostsPhotosVideosReviews

Stream

Peter Magnusson

Shared publicly  - 
 
Yes it's true.  I'm in LA now.  Pretty crazy.

UPDATE.  Ok for the record, the quote "Part of his new job at Snapchat will be building technology infrastructure in-house so that the company can begin to lessen its reliance on partners like Google, Murphy said." is (a) not what Bobby said, (b) not really a focus of my job either.  Thx WSJ for pissing off all my old Google friends.  A more correct statement is that we'll continuously evaluate alternatives, and likely over time develop more infrastructure ourselves, in particular in specialized areas of our apps.  Google is a great partner, and the success of Snapchat would simply not have been possible without Google Cloud, and we expect to work closely together.  Period.
55
4
Ludovic Champenois's profile photoBrad Abrams's profile photoMike Pegg's profile photoLeonhard Gruenschloss's profile photo
11 comments
 
Long time now since an update, Peter!  How's The Big Orange treating you?
Add a comment...

Peter Magnusson

Shared publicly  - 
 
App Engine 1.8.5 is out!  Now with Search!  And much improved PHP support.  Also, even easier now to add an App Engine backend to your Android application.

http://googlecloudplatform.blogspot.com/2013/09/app-engine-185-released-featuring-search-api-and-php-updates.html
19
5
Ivo Encarnação's profile photoIstván Maczkó's profile photo
Add a comment...
1
Add a comment...

Peter Magnusson

Shared publicly  - 
15
Cecilia Magnusson's profile photo
 
Awesome!
Add a comment...

Peter Magnusson

Shared publicly  - 
 
GAE JP night in Tokyo last week was a lot of fun.  Next stop Tel Aviv next week.  See you there.  
Presenters: Dr Peter Magnusson Director of Engineering for App Engine at Google               Greg DeMichillie Director Product Management, Cloud Platform at Google Google App Engine is a complete development stack that uses familiar technologies to build and host applications on the same infrastructure used at Google. It is used by some of the world most successful and demanding global applications such as SnapChat and Khan Academy. Google ...
4
Add a comment...

Peter Magnusson

Shared publicly  - 
 
Lock in, what lock in?

On occasion I encounter the argument that Google App Engine is a proprietary platform, which implies lock-in, which many developers consider a Bad Thing. I’d like to address that complaint. The argument I will be making is this: it’s not as true as you think, it’s mostly unavoidable, and it’s not our strategy - in fact we actively work to minimize it.

It’s not as true as you think

Let’s acknowledge the problem outright: if you develop an application on App Engine, it will require some work to move it somewhere else.

My first “yes, but” to this is to note that there is a bit of an illusion going on. If you’re new to App Engine, you probably feel a sense of lock-in because the runtime environment is very different: it doesn’t allow you to invoke some system calls, write to the file system directly, choose an operating system, or listen to an arbitrary network port, to name a few fundamental ones. These things might be doable with other platforms, especially infrastructure ones, but they are restrictions, not lock-ins to anything proprietary and non-portable. These restrictions are there for good reason, as I’ll point out shortly. And restrictions are always portable.

Software is always built on top of other stacks of software and hardware. No matter how well abstracted, this will leak into your own code to some extent. But the main design principles of App Engine are generic – structure your code so that small front-end workers can respond to requests quickly, pushing longer-running tasks onto a queuing model; separate out short-lived data from long-lived data, and leave the former in memcache and the latter in a key-value store; don’t assume a local file system, because they scale poorly and fail often; don’t hard-code to specific versions of operating systems or libraries; etc. These are good practices for any modern system that strives to be scalable, reliable, efficient and easy to maintain.

The stacks that these abstractions map to are replaceable by you. The Google Cloud Datastore is “just” another NoSQL/NearSQL solution and can be replaced by stacks such as MongoDB; memcache is memcache; MySQL can obviously replace Google Cloud SQL; and the language containers are mostly forward compatible with other containers. Significant portions of the client environment, such as NDB, are open sourced by us already. When we add new building blocks like the Go language, we open source the whole language.

This is not just a theoretical argument. We sample thousands of developers every month to track our customer satisfaction ratings (to a statistical significance sufficient to catch daily variations), and the numbers are rock solid. But it’s important that our developers know that if they became dissatisfied, it should be reasonably straightforward to leave.

And it is. We know this because we’ve had unhappy customers who have decided to migrate off App Engine (shocking). For every such large customer, we do an exit interview to determine exactly how we failed them – and we’re working hard to fix everything that comes up in these reviews. As a side effect of these interactions, we know very well what it takes: for a large application, it’s about 3-4 months of work. Nota bene: that’s for a large, at-scale application; I would posit that this is not materially worse than any other public-cloud-to-public-cloud transition once you have a complex system up and running.

Even if you did code to “standards”, the plug-and-play promise of standards aren’t here yet. Google supports standards - they are key to our success. But the cloud computing and big data areas are new and rapidly evolving. 

It’s mostly unavoidable

Things in life have plusses and minuses.

The restrictions of the App Engine programming model allow us to do a laundry list of things on your behalf: you don’t need to worry about firewalls, most denial of service attacks, viruses, patches, network configurations, failover, load balancing, capacity planning, OS patches and upgrades (in particular security related), hardware upgrades or fixes, certification levels, most security issues, routing, etc.

Because the runtime is minimal for most web and mobile applications, we can start new instances real quick, so that your app can scale fast, and we can move your application to another datacenter when there’s trouble.

You don’t have to wire up supporting services like memcache, email, authentication, backups, SQL, logging, etc. They’re all there, preconfigured and ready to use when you want them.

You can’t build an innovative platform without some measure of lock-in. For example, the Datastore is unlike any other NoSQL or NearSQL service or stack out there. It has multi-datacenter synchronous replication, cursors, distinct queries, projection queries, zigzag merge join, transactional tasks, automatic sharding/load balancing, managed secondary indexes, and multi-row and multi-machine transactions. Our developers don’t want us to dumb down those features to some lowest common denominator; they want us to build more features that leverage the unique underlying software systems.

Engineering is always about trade offs. The more you use someone else's abstractions, the more productive you will be, and the more tied your implementation will be to that platform. But guess what? You got more done. The platform did more work for you. Time is opportunity. Now when (not if) you rewrite your service/app, there will be less of it to rewrite, because the platform did more of the work, and it also guided you to a good structure. Sure, some of the abstractions leaked in to your design. But, they're just different from the other abstractions that would've leaked in had you used something else.

Any good platform will result in this net effect. Namely: that it’s not trivial to migrate, but neither are you artificially locked in. With some work you can move somewhere else. That’s why we set our deprecation policy to one year: no matter what we do, you should have plenty of time to say bye-bye. That’s why we’re serious about our data liberation policy, too: your data should not be locked in.

Giving you options is, after all, one of the reasons we’re doing Google Compute Engine as well. In fact, we’re specifically investing in making it simpler for you to choose appropriate trade-offs between managed and unmanaged infrastructure.

It’s not our strategy

We do not want to lock you in. We don’t like lock-ins. We believe we can both build and run the best underlying stacks and infrastructure in the world. As a company, we disavow artificial use of APIs or Data Jails to tie customers down. Any APIs we design, we strive for them to be the simplest possible encapsulation of the underlying service.

But we go further than this. Appscale (http://www.appscale.com) is a fully open source implementation of App Engine, and we partner closely with them. CapeDwarf (http://www.jboss.org/capedwarf) is a Red Hat project to support App Engine APIs on JBoss and OpenShift, and we work closely with them too, as some of you have noticed (http://goo.gl/5tLgH). With JBoss, for example, Red Hat supports Datastore functionality using Infinispan, and our engineers have worked directly with them (http://goo.gl/9kZjJ) to develop a TCK for compatibility testing.

We actively direct customers to these partners. It’s good for them, but it’s good for us too: a false sense of lock-in simply blocks potential customers from trying us out. And once they try us, they generally like us.

Lock in, what lock in?

I think you’ll find it best to try to leverage key features with whoever is your public cloud vendor, so that you can be more productive in developing your core product. Just structure your code properly. It’s coding hygiene. If you’re a CEO, CTO, or VP of Engineering, your decision on “lock-in” should be: “can we refactor parts such that we could migrate everything in a 3-6 month timeframe, if we had to, without disrupting the business?”

If the answer is yes, that’s all you need to know. Choose a vendor that fits you best, and focus on your product.

The truth is that the public cloud market is a highly competitive business. That’s good for you.
142
102
Ido Green's profile photoIan Douglas's profile photoDaniel Moore's profile photoMatthias Feurer's profile photo
22 comments
 
Only thing for sure is that your LOCKED into only being able to use 20 domain names on your application.
Add a comment...
In his circles
223 people
Have him in circles
2,157 people
Shoshannah Brenner's profile photo
Andrew Alvarez's profile photo
David Gay's profile photo
Mike Fayer's profile photo
Eric Tholomé's profile photo
James Hayes's profile photo
gary silva's profile photo
Anton Sulistiyono's profile photo
Joyce Peterson's profile photo

Peter Magnusson

Shared publicly  - 
 
3D printed App Engine schwag.  Cool stuff.
 
Google App Engine Engine prototype, thanks to the 4planet folks for implementing this master piece.. http://www.4planet.eu/
1 comment on original post
24
1
Cuong Thai (Thái Lý Cường)'s profile photoKeith Perry's profile photoGustav Hållberg's profile photoVikash Kodati's profile photo
4 comments
 
You always get the best toys…
Add a comment...

Peter Magnusson

Shared publicly  - 
 
6
Peter Magnusson's profile photoAdrian Colley's profile photo
3 comments
 
Exactly. I'm trying to think of a suitable analogy. Maybe if Bell Labs started running Linux.
Add a comment...

Peter Magnusson

Shared publicly  - 
 
Check out +Mark Little 's posting about CapeDwarf. And if you're a GAE developer, take CD for a spin.
We've been pretty busy lately so this is slightly delayed. However, I do want to announce that Red Hat has joined the Google Cloud Platform Partner Program as a Technology Partner. Through this program, Red Hat and Google will collaborate on an open source community project known as JBoss ...
3
3
Markus Eisele's profile photoMaxime Gréau's profile photo
Add a comment...

Peter Magnusson

Shared publicly  - 
 
If you're based near Tel Aviv, come hang out with us in a few weeks. (http://www.meetup.com/IGTCloud/events/128866892/)
Presenters: Dr Peter Magnusson Director of Engineering for App Engine at Google               Greg DeMichillie Director Product Management, Cloud Platform at Google Google App Engine is a complete development stack that uses familiar technologies to build and host applications on the same infrastructure used at Google. It is used by some of the world most successful and demanding global applications such as SnapChat and Khan Academy. Google ...
1
Moshe Shaham's profile photo
 
Thank you for posting, I just signed up
Add a comment...

Peter Magnusson

Shared publicly  - 
 
Yupp, people are noticing our Playground.   Check it out.
4
7
Alexey Maloletkin's profile photoAta ul Haq's profile photo
Add a comment...
People
In his circles
223 people
Have him in circles
2,157 people
Shoshannah Brenner's profile photo
Andrew Alvarez's profile photo
David Gay's profile photo
Mike Fayer's profile photo
Eric Tholomé's profile photo
James Hayes's profile photo
gary silva's profile photo
Anton Sulistiyono's profile photo
Joyce Peterson's profile photo
Work
Occupation
VP of Engineering, Snapchat
Employment
  • Snapchat
    Vice President of Engineering, 2014 - present
  • Google
    Engineering Director, 2010 - 2014
Links
Story
Tagline
coder. blogger. entrepreneur. executive. lover. philosopher. dad. engineering director at Google.
Basic Information
Gender
Male
Apps with Google+ Sign-in
lots of good breakfast and lunch choices, very reasonable prices. avoid peak hours since the place is very popular with the locals and it can get very crowded - like at 10 AM on Sundays. usually closed on holidays (unfortunately!).
Public - a year ago
reviewed a year ago
4 reviews
Map
Map
Map