At that moment, the cool new tool instantly becomes a legacy application, and you have to deal with it until you refactor it (ha!) or until you quit to go do something else and leave the next poor sucker to deal with it. A developer decides that a new tool is best, rightly or wrongly, and that tool makes its way into production. It's highly unlikely that anyone ever stood in front of a whiteboard and wrote WE NEED SIX DATABASES!!! with a purple dry erase pen, but that's how things happen when your infrastructure expands rapidly to meet business demand. There tends to be very little in between anymore.) (All of it either open source or proprietary service, of course. So that's web server, web application server, caching proxy server, discovery service, a few services-as-a-service, and six "databases" of various flavors and functions. Here's an example I particularly like: (deep breath) EC2 S3 Qubole MongoDB Memecached Redis Django Hadoop nginx Cassandra MySQL Google Analytics SendGrid Route53 Testdroid Varnish Zookeeper. Spend a few minutes browsing through some of the stacks out there and you'll see that some of the technology collections people have assembled are fascinating. In addition to being useful, it also can be pretty entertaining. It's a great resource to see which pieces companies are using to build their applications. If you're not familiar with stackshare.io, have a look at it. With so many toys to play with, and more coming every day, the toy chest struggles to contain them all. There are so many services, so many tools, so much more compute power available, so many new techniques to try, and always the desire, and the pressure, to solve problems in newer and cooler and more elegant ways.
Application stacks have always been complicated, but never like this.
The complexity of application stacks keeps going up.
0 kommentar(er)
