Increasingly, message queues and workers are intertwined with the language of modern infrastructure. You might rely on explicit solutions like IronMQ or IronWorker. You might not. Whether you do or don’t is irrelevant: MQs and workers are in everything these days.
As a result, when making infrastructure decisions a good understanding of both MQs and workers is essential. The white paper below will take you from a fuzzy understanding to a well-versed conceptualization for both MQs and workers.
I had a lot of fun sharing pre-commit with everyone earlier this week. In case you missed it, here’s a link. As a follow up, I whipped together a quick How-To video.
In it, you’ll follow along as I add a pre-commit hook to a brand new Node.js project. Init a git repo locally, and you can the same as you watch. I’ll take you through adding the initial config, picking your hook, and testing to make sure pre-commit works. Continue reading “Helpful hints: Pre-commit”
Microservices are great! Or, at least that’s what the internet keeps telling me. There are a lot of upsides, but there are more than a few challenges too.
For example, microservices are a polyglot’s dream. Have a Rails app and a use case where Ruby seems a bit too slow? No problem, microservices and Go are a good starting point.
As you might imagine, it’s a nightmare keeping track of style guides and best practices on a per service basis. If only there were a tool to help manage this mess. Oh, hey there pre-commit!
Remember when enterprise shied away from Open Source software? I sure do. The times they aren’t a changin’. Led to by the desire to cut costs and create better products, companies are embracing open source. Business today runs on a mix of open and closed solutions.
Nowhere was this more apparent than at the inaugural GitHub Universe conference last week.
Let’s set the stage first… imagine we operate a windmill farm and want to continually track optimal weather conditions to maximize energy output. What basic steps need to be taken?
Sensors capture surrounding weather conditions
Captured data is delivered to a backend service
The service calculates the expected power generation
Calculated data is delivered to an analytics system
Data is presented in a variety of charts and maps
This process flow sounds similar to the common Extract, Transform, Load (ETL) pattern, however the distinction to make here is that data is pushed from the source to the backend service instead of pulled. This means we need to update our pipeline to be more reactive.
The rise of the API economy in recent years has also given the integration economy a much needed breath of new life. What was once a painful process of dealing with proprietary formats and clunky middleware, has now become a streamlined process via openly consumable cloud-native REST APIs. As such, a new breed of services such as Zapier and IFTTT have come along to make API integrations as simple as a few clicks, while other products such as Slack have made integrations a first class citizen feature of the product itself.
The technology that powers many of these integrations behind the scenes is webhooks, essentially an event-driven callback – when this happens, notify that via HTTP POST. Webhooks are an incredibly useful feature with many services, however as developers, we’ll always find a scenario that’s beyond what’s provided out of the box. With service integrations, this often means performing custom data translations such as field mappings, or additional business logic such as filtering and tagging.
We see a lot of our customers bridge services together using IronWorker because of its direct webhook support, flexibility to run any custom logic in any language, ability to scale concurrently behind the scenes, and “serverless” environment. We say “serverless” in quotes because to a developer, there’s never a need to think or worry about provisioning resources to run and manage tasks at scale. When one of our users shared his custom integration using IronWorker on Twitter, I got in touch to hear more and share his story.
Package your dependencies on IronWorker using composer
This is a tutorial describing how to include and use the PHP package management tool Composer with IronWorker.
Composer is a tool for dependency management in PHP. It allows you to declare the dependent libraries your project needs, and it will install them in your project for you. Packagist is the main Composer repository. It aggregates all sorts of PHP packages that are installable with Composer.