Interview with Eric Brewer

https://medium.com/s-c-a-l-e/google-systems-guru-explains-why-containers-are-the-future-of-computing-87922af2cf95

by agonzalezro • 11 years ago

186 134 11 years ago

zallarak• 11 years ago

"Heroku took off for doing things with Salesforce" - This is not my impression at all.

MCRed• 11 years ago

I'd like a real explanation for why containers are better than unikernels. Yes, unikernals are still early, and containers are convenient, because you have all of linux there... but it seems that running several linuxes on a linux machine is a bit much. One operating system plus XEN plus several applications in unikernels seems more efficient, and more exciting.

But it's the less common choice.

I am guessing convenience is more important than the better solution that would ultimately be more just as convenient and more efficient if it gets enough eyeballs?

ticviking• 11 years ago

I strongly suspect that as time goes on we'll see that containers and uni-kernels converge.

DannoHung5• 11 years ago

I'm completely unfamiliar with unikernels, but I just skimmed a brief description. My first question is: Do they still incur the overhead of running against a Hypervisor like common virtual machines?

Also, possibly a clairification: Unless I'm misunderstanding what you mean by "running several linuxes on a linux machine", I believe you may be mistaken about the way containers work. Only one Linux is really running. And that is the Linux that the kernel comes from. The other stuff doesn't run unless you tell it to (so, no init, no daemons you don't specify, etcetera). Yeah the image size can be a little fat if you don't trim them down, but you can have a container nearly as small as your code is, if you statically compile. On the order of just a few bytes of overhead.

mirceal2• 11 years ago

unikernel basically means that you pack your application and only the lower level bits and pieces that you need to get it working.

you no longer have an OS in the traditional sense.

jacquesm18• 11 years ago

I'd like a real explanation for why containers and unikernels are better than regular run-of-the-mill applications running on dedicated servers. It's almost as if the wild west of the web isn't quite enough and we now need to add another explosion of layers-of-abstraction but this time on the server in order to pretend we have infinite hardware which then becomes it's own reason for existence rather than to simply run efficient software configured properly on properly utilized hardware. As if regular virtualization alone doesn't give enough headaches in trying to figure out why some subsystem does not perform.

At this rate we'll end up shipping containers as 'apps' to the clients machines with a suitable emulator at some point.

All this luxury comes at (considerable) cost and not everybody seems to be doing the math before deployment which more often than not leads to terrible efficiency.

But we're technology fans, so 'oohh! shiny!'.

DannoHung5• 11 years ago

Sorry, but what costs do containers incur? From my understanding, the resource overhead should be exceedingly minimal (disk space would ostensibly be the largest drawback, if you don't spend time cutting out the fat. Personally, I see this as a tooling issue since fat containers are completely orthogonal to how a container really executes). I understand some of the situation with IO isn't perfect yet, but I haven't heard anyone suggest that it cannot be corrected.

mixmastamyk5• 11 years ago

See the shipping container analogy on why containers are so powerful and less work in the long run.

menage7• 11 years ago

Primarily because dedicated servers are a lot less efficient. The more different things you can pack on a machine while still ensuring that the high-priority/low-latency jobs get prompt access to the resources that they've reserved, the higher overall utilization you can achieve (and hence bring costs down),

At least with the Borg containers (I'm not familiar with how Omega and Kubernetes do things), there wasn't any additional layer of abstraction - the fact that there were multiple jobs running on the same kernel wasn't hidden from those jobs (although they didn't have to be aware of it). The containers were purely used for in-kernel resource accounting and control.

mark_l_watson4• 11 years ago

I think that the answer maybe two fold: 1) resource utilization: it is more difficult with physical servers and costs more to run and has a larger environmental footprint. 2) it saves developer time to not worry about resources, OS upgrades, etc.

I like you main point however: I would like to know, given vistualization has X% overhead, what is X?

contingencies2• 11 years ago

Your questions are valid, and you are correct that one size does not fit all. Frankly, the Google use case ('run lots and lots of as-yet-unwritten stuff on lots and lots of identicalish infrastructure') demands thie style of automation, but sacrifices other aspects of the final solution. This is a close use case to public cloud computing providers. However, in many cases (performance, security, etc.) it is not the most desirable model. This dichotomy is in my view one of the key points being overlooked by the dual champions of containerization, docker (non-profitable silly-valley hypetrain for LXC) and kubernetes (rethink of Google's internal container utilization seemingly in response to docker and EC2).

necubi• 11 years ago

I'd strongly recommend reading the Borg paper (http://research.google.com/pubs/pub43438.html). It outlines in clear and persuasive detail why Google started using containers. Their reasons may or may not be convincing for smaller companies, but I'd expect the advantages to start accruing above ~10 developers.

jacobsenscott• 11 years ago

The "special snowflake" problem is the primary reason VMs and containers are better - http://martinfowler.com/bliki/SnowflakeServer.html

While VMs and containers in VMs don't utilize the hardware as efficiently as a dedicated server they make your people much more efficient and happy. Unless you are running at a fairly large scale making your people more efficient gives you a much better ROI than making your servers more efficient.

bcantrill3• 11 years ago

Containers have actually been around for a long, long time -- and have well-known operational efficiencies. So this isn't a "shiny new layer-of-abstraction", it's a tried-and-true abstraction that has been operating in production and at scale for a the better part of the last decade.[1] That said, the developer fascination with containers (which is to say, Docker) is new, and there is a bit of a wild west of abstraction around up-stack abstractions -- but that confusion shouldn't be conflated with the abstraction of OS-based virtualization, which remains a clear improvement over HW-based virtualization and the next logical step function in infrastructure deployment.

[1] https://www.joyent.com/developers/videos/docker-and-the-futu...

mbesto2• 11 years ago

Do you have experience using containers?

Here's my answer for "why": DRY. Once you've deployed hundreds of servers using the same exact Ubuntu 12.04 LTS kernel base, why not just completely abstract the OS away and focus the attention on scaling the OS services that matter? Why is that when I decide that I need to scale out, I need to copy every library of the OS and every line of code for the kernel and redeploy it every time I add a node?

At this rate we'll end up shipping containers as 'apps' to the clients machines with a suitable emulator at some point.

That's exactly the point. Care to elaborate on the downside of such a promise?

btilly3• 11 years ago

Do you want to design for failover of a complex system? Then containers are your friend.

Every dedicated server that you set up has an opportunity to not be duplicated perfectly. Every system that knows about your dedicated server has an opportunity to hard code what it shouldn't. Which makes these a potential point of failure. Add enough of those, and you're statistically guaranteed that the careful architecture that you have for failover is a pipe dream.

If everything is deployed with containers and discovery and the correct provisioning, then dealing with the fact that containers move around forces you to solve all of your other problems. And containers provide an abstraction layer that makes the rest of it straightforward.

Let me illustrate with an example.

When I worked at Google in 2010, I remember reading an article from eBay about how they finally manage to transition everything off of a running data center, without interrupting live traffic, and how much planning it took them. And they were congratulating themselves on what a heroic feat they had managed. Most companies today would still consider that a pretty amazing feat, and would find that challenging.

At the same point time I was learning how things were set up at Google so that you could drop any data center at random with barely any interruption of live traffic, and with no manual intervention required. And Google occasionally does this without warning to important data centers just to be sure that it works.

liveoneggs• 11 years ago

Because rails app 1 needs version x.y.z and rails app 2 needs version a.b.c and RVM sucks and managing gems sucks.

This is, literally, the reason.

You can replace rails with any similarly bad technology. I got this explanation a few weeks ago at my job:

the java build process (I'm not kidding) has such a complex dependency graph that it must spin up full containers to do each build.

----

If dynamic languages supported better packaging/isolation this entire thing would be research projects.

mattmcknight• 11 years ago

I would say containers are primarily an improvement over hypervisors / VMs in performance, not over dedicated hardware. However, they still allow for some of the capabilities of VMs, in terms of elastic reshaping of a cluster. So, if you have a static environment, it's probably not useful to you. If you have a dynamic environment, where you need to frequently repurpose particular machines, but want to do it more efficiently than with a VM, it can be very useful.

In another view, it's another approach to what many look to Chef, Ansible, and Puppet to do. Combined with something like Mesos or Kubernetes, you can quickly deploy to a heterogenous cluster, without a lot of install scripts running.

Some of the other uses cases, such as running multiple containers simultaneously on the same hardware, make less to me.

mixmastamyk5• 11 years ago

but it seems that running several linuxes on a linux machine is a bit much

Perhaps because that's not what happens, the host runs one copy of linux, which namespaces the containers.

sp332• 11 years ago

If you have a statically-linked binary you can just run it in a container. You don't need a whole OS userland in there.

zobzu3• 11 years ago

[...] since the whole userland that you need is included in the binary (worth noting)

you just dont get the debugging stuff (which is okay as long as you can choose)

mark_l_watson4• 11 years ago

Great Interview!

I worked as a contractor at Google in 2013 and loved their infrastructure. It was amazing to fire off a Borg job that used hundreds to thousands of servers, and the web based tools for tracking the job, fantastic logging to drill into problems, etc.

And, Borg was two generations ago!

Even though I am very happy doing what I am now, sometimes I literally wake up in the morning thinking about Google's infrastructure. I now use lesser but public services like AppEngine, Heroku, nitrous.io (like Google's web based IDE Cider, a bit) but it is not the same.

BTW, not to be negative, but while Google is a great home for someone like Eric Brewer, it is a shame that many hundreds of future students at UC Berkeley will not have him as a professeur.

philip1209• 11 years ago

How hard was it to learn these tools as a contractor? I hear that Google is more aggressively making their tools open-source to help the portability of their engineers' skills. Specifically, friends have told me that onboarding at Google is difficult because every tool is a proprietary one built on top of more proprietary systems. In addition, people who leave Google have trouble interviewing because they rely heavily on tools that are unavailable outside of Google. By beginning to contribute more to open-source, I think that it has the potential to make interviewing at and joining Google a smoother experience.

mark_l_watson4• 11 years ago

Good question. I found onboarding at Google really fun and interesting. I took several great classes, the best being the end-to-end class that in 8 hours let you write code that used most of Google's infrastructure - that class was so awesome that I would have payed Google for that day at work :-)

Also, they had code labs that are self paced modules for learning specific tech. I didn't spend much time at work doing code labs, but I could access them at home with my corporate laptop and I went through about a dozen of them at home. One other nice thing is even mentioning that you couldn't figure out something from the documentation or code labs would cause someone to jump in to help you.

Also, I don't think that people leaving Google have problems getting other jobs :-) The retention rate at Google is surprising low, given the pleasant atmosphere there. People leave to go elsewhere, start their own companies, etc. I was 63 when I worked there, and although it was probably not the most awesome place I worked, it was really great.

Apply for a job if you are interested, or go the easier route and get a contractor position.

GauntletWizard• 11 years ago

Onboarding at Google was great; Unlike similarly-sized and oft-mentioned competitors, Google has a set of really good classes that take you through the various systems, showing their design, reasoning, historical anecdotes, etc. Each of these has a more in-depth version, as well as a couple of classes called "Searching Shakespeare" that are designed as a two-day full-stack quickie to build something that uses a little of ever piece.

davmre• 11 years ago

Eric Brewer is still on the faculty at Berkeley, just taking an extended leave at Google. He's scheduled to teach the undergrad database class next fall: http://www.eecs.berkeley.edu/Scheduling/CS/schedule-next.htm...

mark_l_watson4• 11 years ago

That is good to hear, thanks.

Artemis2• 11 years ago

I heard from a Googler that many of other companies' public tools (databases, job schedulers, etc.) were often created by ex-Googlers who missed what they were using at Google.

jedberg• 11 years ago

A funny and somewhat off topic story -- back in 2003, before the Google IPO, Google was doing a recruiting event at Berkeley. They brought a few of their folks with them: their founder Larry, one of their female engineers, Marissa, and some others. They did a little talk, and during the Q&A, professor Brewer told Larry that there was an opening in the PhD program and he was welcome to it. Larry politely declined.

Afterwards I asked Larry, "so, do you think you'll ever finish your PhD, either here or at Stanford?". He said, "If this Google thing doesn't work out I might, but I have a feeling it will work out ok."

It amuses me that Professor Brewer is now working for Larry. :)

bostonpete• 11 years ago

In 2003, Google had over a billion dollars in revenue. I suspect that answer was tongue in cheek.

voronoff• 11 years ago

I suspect the question was as well.

dba7dba• 11 years ago

It amuses me that Professor Brewer is now working for Larry. Pretty sure Prof Brewer isn't exactly tiptoeing around Larry. He can work ANYWHERE.

nickpsecurity9• 11 years ago

One thing that bothers me about the article is that it shows a recurring problem: IT not knowing what it knows. The NoSQL movement didn't notice that NonStop Architecture scaled linearly to thousands of cores with strong-consistency, five 9's, and SQL support. In the mid-80's. Instead of making a low-cost knockoff, like cluster movement did for NUMA's, they ditched consistency altogether and launched NoSQL movement. Now, I see man who invented CAP theorem discuss it while referencing all kinds of NoSQL options to show us the tradeoffs. Yet, there's Google services in production and tech such as FoundationDB doing strong consistency with distributed, high throughput and availability.

http://www.theregister.co.uk/2012/11/22/foundationdb_fear_of...

So, why aren't such techs mentioned in these discussions? I liked his explanation of the partitioning problem. Yet, he and NoSQL advocates seem unaware that numerous companies surmounted much of the problem with good design. We might turn CAP theorem into barely an issue if we can get the industry to put the amount of innovation into non-traditional, strong-consistency architectures as they did into weak-consistency architectures. There is hope: Google went from a famous, NoSQL player to inventing an amazing, strong-consistency RDBMS (F1). Let's hope more follow.

https://static.googleusercontent.com/media/research.google.c...

zobzu3• 11 years ago

thats a pretty good comment actually. there's quite a bit of similarity.

we generally tend to jump into these as "omg awesome new tech" with a very narrow view. But it also helps boosting more though-out techs (even thus it feels less efficient to go through that route first, its perhaps the only route that works with human: try, fail, try again, etc.)

nickpsecurity9• 11 years ago

Yeah we do. My only guess is it's two things: (a) our industry is horrendous at communicating previous generation's wisdom in a usable way; (b) a social phenomenon. Quick example of the first are industry pro's locking up their good advice in obscure, expensive books and cutting edge research silo'd into ACM, IEEE, etc.

The other is a social thing that leads to the "network" effect. People flock to something for whatever reason. This builds a community (or network) that entices others to join. That also tend to forget about other things and reinvent the wheel. Example: much of current work in Web applications aims to solve problems already solved in client-server apps with better efficiency, security, reliability, and portability. Even Facebook went back to that model for mobile IIRC. Good luck convincing most Web technologists to switch to client-server, though.

Whoever solves both these problems will create ripple effects that grow innovation at a heightened, maybe exponentially better, pace. The reason will be a combination of avoiding wasted effort plus visibility into best efforts. I got ideas on Problem 1 but the best minds need to get on Problem 2: it's a gold mine if it's solved.

bitcrusher• 11 years ago

You have some interesting points, however Eric Brewer isn't just 'some Google guy discussing CAP'. He actually invented the theorem... It's also known as 'Brewer's Theorem'.

FWIW, CAP is not about NoSQL or the 'NoSQL movement', it's about distributed systems and distributed shared memory, which applies to a whole range of computing problems.

nickpsecurity9• 11 years ago

I've edited my comment to give him that credit. I understand the CAP theorem applies to many things. The reason I tied NoSQL in is that it's often cited as the reason people traded away strong consistency. Yet, there were strongly-consistent setups with the desirable properties in production and in academia. He and others rarely mention them in such discussions. It's why I tied them together.

otterley5• 11 years ago

NonStop Architecture scaled linearly to thousands of cores with strong-consistency, five 9's, and SQL support.

Admittedly so, but at a very, very high price. Similarly, Sun and SGI had amazing technology in the server and workstation space (after Solaris 2.3, anyway), but over time Linux became "good enough" and we became willing to sacrifice Sun's niceties to save millions per data center.

The mere existence of technology isn't enough; it has to be affordable - and rational managers will have to make cost/benefit decisions that suit their goals.

nickpsecurity9• 11 years ago

True. I always expect this. Yet, Google doesn't fit that profile because they weren't just buying something that works: they were investing countless sums into geniuses and their projects trying to invent new things. It's at that point I expect companies to learn from the past and do better.

jeswin• 11 years ago

The NoSQL movement didn't notice that NonStop Architecture scaled linearly to thousands of cores with strong-consistency, five 9's, and SQL support.

Also incredibly expensive. Take this case, Google took off because they were able to scale-out with off-the-shelf hardware, compared to the millions banks were pouring in for scale-up configurations which handled much less load. Scale-up can quickly hit hard limits, before it becomes exponentially expensive to continue on the path. This is true even today.

NoSQL movement, if you wanna call it that, took off because most apps (including Google, including Financial Services, even Health Care) don't need some types of consistency offered by relational databases. Many large apps are significantly de-normalized and have many foreign-key less tables, often filled up by scheduled jobs. That's fine for most apps; NoSQL architectures recognize that and users consider that in design.

For the majority of use-cases out there, NoSQL databases offer enough consistency. For the remaining use-cases, there are tools available in NoSQL databases to make them work, though it requires a bit of work.

andyidsinga5• 11 years ago

yep. see also : shared nothing architecture

AlisdairO• 11 years ago

For the majority of use-cases out there, NoSQL databases offer enough consistency.

For applications with a nontrivial data model, ensuring that each logical operation only does a single document update (or that multiple nontransactional updates cause no conflict in maintaining consistency in the presence of other logical operations) is actually really challenging - and it adds a substantial design overhead to every new feature added. I think you're being extremely optimistic in your assertion that NoSQL systems are that widely safely applicable. My experience has been that NoSQL-based systems stay mostly-consistent because they happen to experience very little concurrent activity, not through understanding/design on the users' part.

This is not to make light of the situations where NoSQL systems shine, but the idea that higher levels of consistency are rarely useful does not match my experience at all.

NoSQL movement, if you wanna call it that, took off because most apps (including Google, including Financial Services, even Health Care) don't need some types of consistency offered by relational databases.

I'd say that Mongo (for example) took off because:

- They really nailed the setup experience for new users (which RDBMSs historically sucked at).

- The data model is much easier for simple apps.

- They had some fairly creative techniques for making their system look good - unacknowledged writes, and claims of support for replication which didn't really fully work.

- Most programmers don't really understand the ins-and-outs of maintaining consistency.

marktangotango2• 11 years ago

> Many large apps are significantly de-normalized and have many foreign-key less tables, often filled up by scheduled jobs. That's fine for most apps; NoSQL architectures recognize that and users consider that in design.

There's a boat load of assumed knowledge in this quote, how likely is it that someone not familiar with rdbms would know what a foreign key is, for example? Not very likely I think. I posit you give developers too much credit.

nickpsecurity9• 11 years ago

In startup mode, I expect companies to do whatever works. Google's initial decisions were correct. Later, they dedicated expensive teams to inventing brand new solutions for about every aspect of their operation. That's when my critique apples. For instance, they might have looked at expensive NonStop, identified what they could copy with COTS tech, and made a cheap knockoff. They could've done the same with prior MPP or cluster tech which already scaled to thousands of nodes with open source management tools and microsecond latency. Much more efficient than web stacks, too. The one example I saw of them copying and improving past methods was Google File System. As I predicted, that good choice laid foundation for awesome stuff such as BigTable, Spanner, and F1.

NoSQL movement's origins are highly debatable. Here's what I saw in its beginning: an explosion of articles on the subject after a few success stories about big companies doing massive scale on cheap servers. Zealots argued that mature, strong-consistency solutions had problems. So, instead of fixing those, we should just ditch them and strong consistency for The New, Great Thing. The only time I even saw a real analysis of cost-benefits was a few articles which focused on a narrow class of applications where data consistency didn't really matter. So, my conclusion was that the movement was two things: 95% a social phenomenon that happens with each IT fad; 5% a result of weaknesses of relational model and tools. That last part makes sense and is why I've always opposed RDBMS's.

On your last point, do you have a citation that shows weak consistency databases offer enough integrity for "majority of use-cases?" I thought the majority of use cases for databases were protecting data that's important to a business: orders, billing, HR, inventory, customer information, and so on. I usually just tell them to use PostgresSQL and that covers it with high reliability. If you really can back your claim, though, I'll be glad to start transitioning my R&D toward designs that trade against integrity of data.

rdtsc3• 11 years ago

There is hope: Google went from a famous, NoSQL player to inventing an amazing, strong-consistency RDBMS (F1). Let's hope more follow.

The problem is at a large distributed scale forcing consistency is basically fighting with the laws of physics. Is something in Australia always consistent with something in US? Well "same time" is a funny thing in physics because it doesn't actually exist. So we have to work really hard to keep consistency going.

To illustrage, here is how Spanner (F1) works:

---

Spanner's 'TrueTime' API depends upon GPS receivers and atomic clocks that have been installed in Google's datacentres to let applications get accurate time readings locally without having to sync globally.

---

I call that a cludge in the general sense, not amazing future technology. Yes if you can afford to install GPS antennas on your datacenters you can handle it and it is ok. But it is a crutch. "Well but there is NTP one might say say". Yeah there is, and connectivity to that fails as well.

The one interesting research area though is CRDTs. These are datatypes that know how to auto-converge to a known value even if they experience temporary inconsistency. So you basically experience temporary inconsistency but it fixes itself.

ChuckMcM• 11 years ago

I was pleased when I read the spanner paper to see that they had gone to locally authoritative stratum 0 clocks. I long time ago in a different universe it seems, I struggled with the notions of replcated naming logs which needed to converge to a common and consistent results. It wasn't until I got to play with the combinator technology at Blekko did I feel like there was a good answer to the problem. Clouds of idempotent expressions of execution don't need clocks at all, if you have them all, you have your answer. That was a neat result.

lallysingh• 11 years ago

Afford to install GPS antennas? My last 4 phones had them. So does my watch.

ForHackernews2• 11 years ago

I don't see how using GPS receivers for a time index is "a kludge". It seems like an extremely sensible and practical solution to the problem. Hey, turns out we've already got this satellite constellation broadcasting an extremely accurate time signal!

It's a hack, in all the positive senses of the word.

nickpsecurity9• 11 years ago

Fighting the laws of physics is a great comparison. Every chip designer trying to create the illusion of a sequential (or multicore) machine with a specific memory model fights the laws of physics. So do people building bridges, designing planes, and trying to maintain space stations. The greatest weapon we have after human ingenuity is using good engineering principles built on what we've tried and learned.

So, back to this current example. Synchronizing time was a huge problem for consistency. They had expensive, highly-custom datacenters throughout the world. Yet, there wasn't even a solution worth buying that wouldn't cost a fortune or need new infrastructure. An engineer noticed that a time-source existed which all datacenters could sync with using affordable, COTS equipment. One among others. So, they used that to solve the critical problem, solved other problems with other technologies, and integrated the resulting components into a solution to their real problem (F1).

What I've just described is not a hack: it's Engineering 101. Identify the problem(s), look for known solutions to it, adapt them to your needs, and deliver the solution. Their use of GPS to solve a problem that otherwise would cost millions of dollars to solve is exemplary engineering. Given datacenter costs, using this at each one would barely be a blip on the budget sheet and will get easier to deploy as adoption increases (network effect).

kayman2• 11 years ago

I love the idea of using containers. Due to linux popularity and google's backing, containers will be next.

But FREEBSD had jails since back in the day. What's the benefit of containers over bsd jails?

otterley5• 11 years ago

Linux has copy-on-write block devices that make it possible to efficiently layer container filesystems. FreeBSD has no such thing as far as I know; the best you can do involves hard links (correct me if I'm wrong).

bch2• 11 years ago

https://en.wikipedia.org/wiki/UnionFS

Edit: addendum

Additionally, a hardlink solution (as you point out) really doesn't sound too outrageous to me. A trivial tool to write to manage immutable things like binaries. Or is there some trouble I'm failing to see (possible)?

tachion• 11 years ago

You are incorrect, FreeBSD has ZFS file system as a first class citizen and that allows all these things (and much more). Check out tools like iocage[1] that are using it in very user friendly manner.

[1] https://github.com/iocage/iocage

TheIronYuppie4• 11 years ago

Disclaimer: I work at Google on Kubernetes & Containers

I mentioned earlier - https://news.ycombinator.com/item?id=9570639 - but the biggest thing is not isolation, it's portability. You do not care what you're running on, just that you have a certain amount of disk, CPU and network available to you, and the rest you handle yourself. That gives your organization a crazy amount of flexibility in moving that ball of stuff around.

otterley5• 11 years ago

You do not care what you're running on, just that you have a certain amount of disk, CPU and network available to you

Does Kubernetes provide those guarantees to the containers? And, if so, what does it do once those guarantees can no longer be met, say, due to neighbor growth?

kayman2• 11 years ago

You can also archive and move jails as well...

andyidsinga5• 11 years ago

imo, if containers are the future ( very plausible ), then, things like Aws lambda are just as plausible if only just a bit further out.

I think this is the case due to granularity of workloads and what apears to be a continuum in the workload container from metal > vm > containers > lambdas (as first class workloads).

fun stuff

TheIronYuppie4• 11 years ago

Disclaimer: I work at Google on Kubernetes

True, lambda is DEFINITELY an advance, but it's more like the salmon at a buffet that includes steak and chicken. Some applications will need just the ability to run code (lambda), some will need defined environments (containers) and some will need total isolation (VMs/bare metal). You'll see a mix of all of these in every mature environment - some things do not fit. For example, it's super unlikely that you'd be able to run a trading app on Lamdba (needs 10GB/sec of direct network access & memory); similarly it'd be totally unnecessary to run a thumbnail processor on bare metal (though you could, of course).

andyidsinga5• 11 years ago

good points but I'm not sure anything about the fundamental lambda architecture prevents it from being applied to high bandwidth or low latency uses. especially if lambda functions are orchest rated to run in the metal ...think: kernel module implements lambda, then add orchestration glue up in user land

la6470• 11 years ago

With all these container talks people forget Solaris zones which were pretty advanced sort of containers in Solaris. However Sun was honest about not mentioning zones as the solution for everything. The most important problem with containerization is that due to dependence of multiple containers on the same kernel of the host or VM OS , any kind of upgrade specially the security patching is virtually impossible to do without taking full downtime.

voidr• 11 years ago

I have been using Amazon Web Services and other cloud platforms for over a year now, and I never really felt that VMs were the bottleneck in any way. Can someone explain to me the advantage of containers here?

I know that containers are faster because they don't virtualize the hardware, however it comes at the cost of security.

TheIronYuppie4• 11 years ago

Disclaimer: I work at Google on Kubernetes & containers.

I tried to address it here: https://news.ycombinator.com/item?id=9570639

But in summary, the basic thing that containerized software offers is inherent portability and simple composition. VMs aren't going anywhere; running a container on top of them just makes everything more powerful.

jesstaa• 11 years ago

Containers, like virtual machines before them, aren't the future of computing. They're how we manage legacy apps.

The future of computing is not this horrible kludge.

vidarh3• 11 years ago

No matter what, we will want more isolation, not less.

But I sort-of agree in that we're just starting to make the transition from whole-os VMs to app containers, with a rare few going further. But cgroup/jails type isolation is lightweight enough that we can easily apply it at a much finer-grained level.

TheIronYuppie4• 11 years ago

Disclaimer: I work at Google on Kubernetes

The problem containers are trying to solve is not isolation of environments (though, that's a tremendously good outcome).

The problem is how do you develop microservices that are self-contained, easily composable and inherently portable. It doesn't matter if you're running on Java 1.1 on AIX 3.0 or Node on Ubuntu 26, if I have a ball of computing providing a service in Dubai, and want to move it to Ireland to take advantage of computing space that just opened up, containers make that trivial (and about a million other scenarios).

digitalzombie• 11 years ago

I saw a kubernete talk at a local meetup.

Google have 40 programmers dedicated to that project. It's still very beta btw all programmed in Go.

There's also mesos and I think you can use both in tandem since they're targeting a different thing.

Anyway if anybody is doing or thinking about containers check Kubernete and Mesos out. Also of course docker and rocket. Kubernete officially support docker and will be supporting rocket.

There are also article about how rump kernel are better than containers. Just fyi.

dunkelheit• 11 years ago

Can someone explain or provide an educated guess about what is the google's strategy with kubernetes here? Surely containers are hot now and it is nice to have a stake in the game but borg has been one of their key competitive advantages. What is the profit in making an open-source alternative?

inquisitiveio• 11 years ago

I have been wondering the same thing. I suppose it's partly because it was only going to be a competitive advantage as long as as containers where not commoditized which seems to be the direction its now heading.

Interview with Eric Brewer

Related Stories