Attending AWSSummit 2014 in Berlin
Join the DZone community and get the full member experience.Join For Free
last week i attended the aws summit in berlin . i honestly hadn’t heard about these venues before, but a friend was going and asked me whether i would join, so i said “yes”, in particular since it was free.
i was pretty surprised be the size of the whole event, probably more than a thousand people were listening to werner vogels keynote and four tracks of talks on all aspects of amazon’s web services. the location itself (the postbahnhof in the eastern part of berlin) was actually pretty bad. seating capacity was insufficient, people barely fit the keynote and later on people often had to be turned down because rooms were filled to capacity. initially, they were also still checking all the badges with a very low throughput handheld qr code reader, but later people were still often stuck in the narrow corridors of the building. so, ironically, a lot of bandwidth problems, and little of the elastic scaling aws is priding themself on in the real world.
the event hit of with a nice keynot by werner vogels, cto of amazon. what i found interesting, though, was that they were still trying very hard to sell the benefits of moving to the cloud. by now i think that it’s pretty clear to everyone what the advantages are, like being able to scale resources up and down quickly, or not having to worry about buying, hosting, and mainting physical servers. other issues like privacy were stressed as well (and very obviously to address concerns about the nsa or other people spying into cloud infrastructure). then again, i think in reality issues are not as clear cut and there sometimes are good reasons why you don’t want to move all your stuff into the cloud, so one has to make a balanced assessment.
there were also egregious claims like aws being a key factor in lowering failure of software projects. i don’t think buying too many servers or too few is really the single reason for failure, what about misspecification, miscommunication, and underestimated complexity? at another point, vogels explained how scale effects allowed amazon to lower the prices continually (you lower prices, you get more customers, you expand your hardware, you get economics of scale, you can lower prices, etc.), whereas i think that advances in hardware efficiency also play a key role here.
i was particularly interested in learning about apache kinesis. based on the documentation (“real-time this, real-time that”) i was under the impression that it was a storm like stream processing system, but then i learned that it was mostly infrastructure for ingesting huge amounts of event data in a scalable fashion in a buffer which holds data for later analysis. so it’s really more a scalable, persistent, robust transport layer than anything else. you can have multiple workers consuming the kinesis stream, for example, by hooking it up to a storm topology, but at the basis, it’s only about transport. the unit of scale is a shard, where a shard will be able to handle 1000 transactions per second and 1mb/s ingoing and 2mb/s outgoing data , which i thought wasn’t really so much.
just to put this into perspective: for one of our projects with streamdrill (you know this’d be coming, sorry about that, but it’s really something where i can talk from my own practical experience), we’re easily consuming up to 10k events per second, with events being up to about 1kb, on a single machine, giving roughly a ten-fold speedup and throughput versus the clustered solution. you can very clearly see the cost of scaling out. first you have to accept a performance hit which comes from the whole network communication and coordination overhead.
what aws and many other guys are doing, is that they are constructing building blocks for infrastructure. then you can put kinesis, storm, and s3 together to get a scalable analysis system.
on the other hand, an integrated solution can often be much faster as in our case with streamdrill which combines data management, analysis, and storage backend (in-memory). somehow, if you use existing service you may end up in a situation where you lost the opportunity to do important optimizations across modules.
in a way, modularization is the standard game in programming, you try to isolate services or routines you need often, building abstractions in order to decouple parts of your program. if done right, you have something with high reuse value. i think all the standard computer science algorithms and data structures fall into this category. cloud computing, on the other hand, is a pretty new topic, and people are basically making up abstractions and services as they go along and you don’t always end up with a set of services which will lead to maximal performance. in a way, these services give you a toolbox, but if all you have are pipes, there things you cannot build if you need other building blocks, too, like filters.
interestingly, when it comes to data analysis, i think that there are other problems with this approach. as i’ve discussed elsewhere , we’re not yet at the point where you can just pick a data science algorithm and use it without knowing what you do. machine learning and data science is not yet just about building infrastructure and abstractions but also still about finding out how to properly solve the problems there are.
Published at DZone with permission of Mikio Braun, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.