DevOps has become a crucial factor in IT’s success. It’s been a long journey but we are finally here.
Over 10 years ago, about every IT department—small or large—was chaotic and lacked a balance of collaboration, processes, automation, and monitoring on both sides of development and operations. Application development followed waterfall models, while applications tended to be monolithic and deployments were labor intensive but not frequent. What resulted was missed business opportunities and horrible experiences for engineers (i.e.,
With all the talk and content praising the microservices design approach, you might think the monolithic architecture is outdated and inefficient, but don’t limit your options when it comes to your application and, indeed, your company. In certain circumstances, a monolithic design is ideal, said Steven Czerwinski, a former Google employee and current head of Engineering at Scalyr, a server log metrics and monitoring systems developer.
I’ve been an Integration Architect in IT engineering here at MuleSoft for about one and a half years. When I arrived, our group had a full queue of potential development projects, but were still maintaining many legacy and point-to-point applications created by external developers outside of IT. Each application was designed well and accomplished singular goals that satisfied the use cases from the business owners, but it’s been challenging to maintain these legacy applications within the context of our ever-evolving products.
Once upon a time, I couldn’t do without my middleware. To make my application resilient and scalable, and to allow it to talk to everything else in the enterprise, I had no choice but to stand up an ESB in my architecture. It was literally in the middle of everything I did. Then, when I moved to the cloud, my world began to change.
All CIOs share a common priority: ensuring development teams have the skills and experience to apply best practices that support the organization’s needs effectively. Certification is one the most important qualifications to help evaluate a team’s skill set, and are considered a strategic tool for building a foundation of expertise to drive both individual and team success.
A short while back I wrote a piece, Why Message Queues Suck. The gist of the piece is that for the same labor and overhead required to implement and maintain an inter-service notification architecture using message queues, you can just as easily implement inter-service notification by Direct To Endpoint communication. (Please see Figure 1 below.)
As you might imagine, the piece caused quite a stir, particularly on Reddit.
Keeping up to date with the latest versions of NodeJS comes with several advantages including access to the latest language features (as seen in Node Green) as well as performance improvements that can have a direct impact on your web services. The benefits are even more prominent in the context of a microservice architecture where there’s a constant need to orchestrate and maintain different versions of NodeJS across many instances.
Application program interfaces (APIs) have become extremely valuable to hugely successful companies such as Facebook, Twilio, and Expedia. They are, in fact, a strategic investment for any business. You can offer your APIs as your entire business, have your APIs become part of your core business, or even use other companies’ APIs to build your business – you get the idea.
In this post, I will show the differences between chaining flows with VM transport versus chaining flows with flow reference. When I need to divide my Mule flows into reusable units, I often break them into smaller flows and then chain them together in a main flow.
Flows can be chained together using flow-refs or using VM connectors; most recent examples use the flow-refs. However, flow-refs are a Mule 3 addition and in Mule 2 VM connectors were used to chain flows.
This all began with a very popular request: “We want to be able to throw an Exception from a flow”. The motivation for this is that it’s fairly common to run into “business errors” (errors not related to the handling and transmission of data but the data itself) which should actually be treated in the same way as a connection or system error (things like the remote endpoint is down).
Given the popularity of the request we decided to look into it and started by asking: “which are the use cases in which you would throw an exception?”.
MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.