In Part 1 of this blog post, we outlined 2 Key Agile Themes (delivery efficiency and adaptable designs), Then, we used the themes as a guidepost to identify 10 features of an application platform. In Part 2, we provide examples of how the vFabric Application Platform delivers against these 10 features:
1. An application framework that minimizes coupling
2. An application framework with great support for Unit and Integration Testing
3. A messaging technology that can run anywhere
4. An application platform that supports performance testing in the development cycle
5. An application server that streamlines application deployment Continue reading →
Using an “agile process” is listed as one of the Top 10 Reasons for Project Success. So, it’s not surprising that everyone wants to be agile these days. There are numerous books and blogs available that explain how to adopt agile practices from a people and process perspective, but what about technology?
Do the decisions we make when choosing our “build, run and manage” application platform affect our ability to adopt agile practices?
To answer this question, we’ve looked at the principles behind the agile manifesto and identified two core themes to help characterize the agile features of application platforms.
The 2 Key Agile Themes
Theme 1 – Delivery Efficiency
Adopting agile practices means we need to deliver working software fast and often and in a sustainable way i.e. we need to choose application services that streamline the software delivery cycle.
Theme 2 – Adaptable Designs
Adopting agile practices means we need to create simple architectures that can support the fast changing business requirements we see emerging in today’s dynamic markets i.e. we need to choose a application services that encourage developers to create simple and adaptable designs.
So you've heard about this VMware vFabric RabbitMQ "thing" but why should you care? Sure you might have heard things like "Rabbit will make it easy to glue your apps together" or "making async apps is a snap with Rabbit," but isn't it just one more thing to break?
When Alvaro and I came to RabbitMQ, we weren't searching for a "messaging" solution. We were looking for an "I need to solve XYZ problems now, and no a database won't work" solution." For me, it was needing to queue up incoming spam retraining requests and process them asynchronously. I needed to be able to add or remove workers at-will to scale with the number of requests coming in…and I needed to be able to do all this while ensuring each request was processed only once. Oh…and by the way, the front-end message receivers and the backend workers weren't necessarily written in the same language.