I have been asked so many times about DataWeave Performance during my time in the field. This is because developers try to find arguments to not use it when they realize that a new and proprietary programming language is introduced. Most of the time they have the same “natural response” of resolving the problem by going to the known and comfortable zone called “Java.”
Anti-patterns can be hard to spot. Anti-patterns are the inevitable outcome when a rule set is applied so rigidly that it yields the opposite of the original desired outcome.
User experience is no exception to anti-patterns. As UX principles and practices become more commonplace, enterprises are finding themselves faced with an increasing number of failures in the nooks and crannies of the experiences they are crafting.
Many customers I meet are either evaluating or beginning their implementation of microservice architectures. Some of these customers are coming off big-bang projects that have failed to replace large legacy assets.
Predictability is the primary reason companies embrace agile over waterfall. The full slate of reasons vary depending upon the context of the company, and it would certainly not come as a shock that many companies embrace agile because it’s hip. But for the most part, large companies (aside from the ones trying to be hip) tend to embrace agile for predictability with a capital P.
If you were existing anywhere but under a rock for the last few weeks, then you were probably subjected to a gauntlet of GDPR notifications from the websites that you frequent, including ProgrammableWeb. They may not have even mentioned GDPR or the General Data Protection Regulation. But the sudden onslaught of these messages while visiting those sites, or via email, or both was unquestionably due to the mad rush by website operators (your’s truly included) to meet the May 25 deadline for complying with the sweeping privacy regulation that was established by the European Commission (EC).
In a previous life, I worked primarily with the operational side of the IT business, which is concerned with monitoring and operational alerting. The requirements we implemented were variations on a theme that typically started with the business asking IT to provide an SLA for “availability” of a service as well as an SLA for the responsiveness of a service. On the surface, these requirements were clean and simple, but in practical terms, things got murky very quickly.
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.
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.