InfoQ Homepage Presentations Learning from Five Years as a Skype Architect
Learning from Five Years as a Skype Architect
56:16
Summary
Andres Kutt discusses his experience as architect at Skype for five years, sharing some of the lessons learned: rules of thumb do not always apply, functionality is important, use simple solutions, buzzwords are dangerous, the architecture needs to fit into the organization, and communication is important.
Bio
Andres Kutt has been with Skype since 2005, leading a growing team of architects. Before that, he worked as IT Deputy Director General for the Estonian Tax and Customs Board, and as a free consultant for financial institutions.
About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Aug 12, 2010
Community comments
DB and business logic
by Robert Sullivan,
nice presentation
by Leandro Coutinho,
DB and business logic
by Robert Sullivan,
Your message is awaiting moderation. Thank you for participating in the discussion.
Good to hear that not all have pursued the fad of storing all the business logic in the middle tier, as we've been told by many gurus. After building some significant stored procedures, and then pondered the corresponding complexity of J2EE EJBs and/or Hibernate and burying the logic in xml, and coming to the same conclusion as Andres, I will meld a couple of his points - the architecture needs to fit the organization, and simple is good.
Maybe business logic in the db is not a good fit for everybody, but we must stop blindly accepting the latest wisdom as the end-all be-all truth.
The pgQueue was very interesting idea also, especially simplifying from once-and-only-once to at-least-once. There was a post recently here on Infoq that was about a very similar idea, except it was unfortunately a little misleading in that, perhaps for fanfare, it stated that there was no need for a queue. But they were still building all the queue infrastructure, it was just a simplified queue. So the idea of a queue structure still holds and is very useful, as can be illustrated in languages like Erlang, which supports concurrency nicely, offering tremendous performance.
It would be very interesting to hear more about this design, and also the various tools available from Postgres that were mentioned.
Thanks for the interesting talk!
nice presentation
by Leandro Coutinho,
Your message is awaiting moderation. Thank you for participating in the discussion.
very nice presentation. some databases have very useful features. thank you!