As a stakeholder, I want the smallest possible time between project kick-off and tangible results, decreasing time to value. As an architect, I want a great platform that is responsive, secure, scalable, and reliable, with out of the box application tracing, monitoring, logging, and alerting. As a developer, I want the freedom to experiment, the freedom to fail-fast and to pivot as quickly as possible.
Join enfuse.io as we kick-off a new blog series where we explore Azure Spring Cloud in granular detail.
This series is going to be a little bit different than what we’ve done in the past. We’re going to mix this blog series with different media that include video tutorials and podcasts. We’re so excited about Azure Spring Cloud and the potential it has to change the game for so many different clients.
Recently Dave Miller (Director of Engineering for enfuse.io) and I gave a talk about building Production Data Pipelines through Test Driven Development and Pair Programming. We were committed to using as minimal slides as possible, and in lieu of a traditional presentation, we wanted to develop a data streaming application live within the span of 30 minutes (our available presentation length). The point of the presentation was to demonstrate how to build a production data pipeline from scratch using pair programming and test driven development. So we didn’t want to have to spend an inordinate amount of time tuning and building infrastructure.
A production data pipeline requires that we have fantastic testing from beginning to end. The Spring Framework and collection of Spring projects and starters give us the freedom to focus on the code, not the boilerplate. So it was a no-brainer to have the live code demonstration in Java and Spring.
Production means so much more than just testing. It means that we have to have highly available and scalable applications — in this case data processing apps. We also have to be able to have one code base, but different behavior throughout environments.
Production means so much more than just testing.
Sandbox applications shouldn’t be accessing integration or production databases or middleware. Integration apps shouldn’t be hitting sandbox endpoints. Application instances should have less computation and memory resources in the sandbox environment versus the production environment. Configuration for each application should be externalized, versioned, and editable without having to touch the code base. Credentials should be kept encrypted, even in private Github repositories. We shouldn’t have to provision, configure, and deploy a cloud Kafka environment — these should be things the cloud should provision and manage for us.
Our first blog in the series we’ll be diving in quickly — developing and deploying an MVC application in Azure Spring Cloud. We’re then going to move on and take a really deep look at logging, tracing, and alerting. Then we’re going to put the spot light on Azure Event Hubs and how that integrates with applications running in Azure Spring Cloud, along with a number of other cloud native services provided by Microsoft in the Azure Cloud. The blog series will wind down with us developing and entire end-to-end data pipeline with multiple environments for application promotion.
So be on the lookout, we have some exciting stuff coming up, and this is just the beginning for Azure Spring Cloud!