Last year on February 14th we published a blog post on “Building the Ultimate Valentine’s API.” Personally, I had a lot of fun writing it and finding facts related to how we spend our Valentine’s Day (though I forgot to bring home chocolates and flowers to my wife, who was none too pleased)! To prevent history from repeating itself, we’re taking things a step further this year with a Valentine’s Day webinar on why Integration + Cloud = A Match Made in Heaven.
I spoke at a Gopherfest meetup about the Go Programming Language. Together with an awesome colleague (Miguel Torres) we talked about Project Flogo and the lessons we learned building it.
This year I wasn’t able to attend re:Invent, but I did want to do something nice in between the live streams and specifically around Serverless compute and AWS Lambda.
Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume — there is no charge when your code is not running. With Lambda, you can run code for virtually any type of application or backend service — all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability.
With Project Flogo you can visually create Ultralight Edge Microservices and run them anywhere. But what if you want to run those incredibly light microservices using one of the most powerful container management platforms, Kubernetes?
Prerequisites # As described on the Kubernetes website
Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery.
SaaS has become the default way enterprises acquire software, which means any given organization has (or will have) dozens of apps that need to talk to each other. The average Marketing department uses around 30 different SaaS apps, and HR isn’t far behind. This webinar looks at the integration challenge that creates and when iPaaS is the right level of abstraction to solve it.
Last month TIBCO added the ability to add custom activities to TIBCO Cloud Integration — Web Integrator (I’ll use Web Integrator going forward). The Web Integrator experience is “Powered by Project Flogo”, so when you create your own extensions for Web Integrator, and use them in every flow that you want, those activities will work with Project Flogo as well. In this blog post I’ll walk through creating a new extension that connects to IFTTT using the WebHooks service.
Back in 2012, the engineering team at Heroku created a set of best practices for developing and running web apps. That document, consisting of 12 important rules, became the 12 Factor App manifesto. It gained a lot of traction over the years, especially as microservices took off. Along with microservices came a wave of related practices and tools — git, DevOps, Docker, Configuration Management — that all reinforced these principles.
Pretty much all the large cloud platforms provide not only a great visual interface to get things done, they also have a great command line interface. As much as I like a great UI when browsing the web, I tend to favor the command line when I’m focused on building things.
In 2016 TIBCO announced Project Flogo as an ultra lightweight integration engine — up to 20 to 50 times lighter than Node.js and Java Dropwizard. It’s open source and easily extensible, which means you want to make sure the activities you build keep working after each check-in. The question is straightforward: how do you test your activities every time code is pushed to Git?
