Why real integration developers ride Camels
•3 likes•1,521 views
Download to read offline
Report
My talk from Red Hat Summit 2015 about apache camel
Recommended
More Related Content
What's hot
What's hot(20)
Viewers also liked
Viewers also liked(12)
Similar to Why real integration developers ride Camels
Similar to Why real integration developers ride Camels(20)
More from Christian Posta
More from Christian Posta(20)
Recently uploaded
Recently uploaded(20)
Why real integration developers ride Camels
- 1. Why real integration developers ride Camels
- 2. Christian Posta Principal Middleware Specialist/Architect Blog: http://blog.christianposta.com Twitter: @christianposta Email: christian@redhat.com • Committer on Apache Camel, Apache ActiveMQ, Fabric8 • Recovering consultant • Spent lot of time working with one of the largest Microservices, web- scale, unicorn companies • Frequent blogger and speaker about open-source, cloud, and microservices
- 3. Kenneth Peeples JBoss Technology Evangelist Blog: www.ossmentor.com Twitter: @ossmentor Email: kpeeples@redhat.com • Prior Public Sector Consultant with a concentration on Security • Blogger and speaker with a concentration on Mobile, Integration, Cloud and Data Services
- 4. • Open-source Camel riding • Competitive claims • What our customers say • Why you should ride Camels too • Demo Agenda
- 6. 6 Apache Camel Apache Camel is an open-source, light-weight, integration library. Use Camel to integrate disparate systems that speak different protocols and data formats
- 8. Features ● Enterprise Integration Patterns (EIPs) ● Domain Specific Language to write “flows” or “routes” ● Large collection of adapters/components for legacy systems, B2B, and SaaS ● Strong Unit test/Integration test framework ● Expression languages ● Data Formats ● Tooling with JBoss Developer Studio
- 10. Not so open source…
- 11. • Apache Camel is 100% open source • JBoss Fuse (built with Camel and other Apache projects) is 100% open source • Vibrant communities • Mailing lists • Code commits • Issue trackers • Visible community members • Blogging, books, social media Is Camel open source or open core?
- 13. • Well…actually, Camel significantly reduces the amount of code • “Went from 90,000 LOC to 2,000” • Without Camel DSL: https://gist.github.com/christian-posta/6dc3b96f964c9706fa63 • With Camel DSL: https://gist.github.com/christian-posta/2d0e119d71ca1808ccba “I cannot understand the benefit of Apache Camel as a lot of code is required”
- 14. • Well… let’s be honest; every library has a learning curve • What that means is flexibility • Need guidance and best practices? • Books, community, support • Starting off “basic” and leveraging more as become comfortable with the API “So many different ways to implement a solution with Apache Camel”
- 16. • Well… actually, checkout the new Fuse tooling! https://github.com/fusesource/fuseide http://tools.jboss.org/downloads/jbosstools_is/index.html • Demo perhaps? “No drag-and-drop tooling, no data mapper”
- 17. • Camel is not an ESB • Pick the right tool (architecture) for the job! • Not forced into expensive, mountainous suites of applications • If you want to compare ESBs, don’t compare with Camel • Do compare with JBoss Fuse “Apache Camel doesn’t do what ESB X does”
- 18. RED HAT JBOSS FUSE Development and tooling Develop, test, debug, refine, deploy JBoss Developer Studio Web services framework Web services standards, SOAP, XML/HTTP, RESTful HTTP Integration framework Transformation, mediation, enterprise integration patterns Management and monitoring System and web services metrics, automated discovery, container status, automatic updates JBoss Operations Network + JBoss Fabric Management Console (hawtio) Apache CXF Apache Camel Reliable Messaging JMS/STOMP/NMS/MQTT, publishing-subscribe/point-2-point, store and forward Apache ActiveMQ Container Life cycle management, resource management, dynamic deployment, security and provisioning Apache Karaf + Fuse Fabric RED HAT ENTERPRISE LINUX Windows, UNIX, and other Linux
- 19. Ultimately: Our customers care about making more money. How can these tools help them do that?
- 20. What our customers say
- 21. http://www.redhat.com/en/resources/value-red-hat-integration-products • Six organizations studied • Telecommunications, IT, shipment and logistics, and document management • Three year ROI of 488% • Payback time of 8.2 months
- 22. • 51.5% more applications integrated per year • 40.8% fewer FTEs per application integration • 62.8% less downtime related to integration • 18.1% improved performance • 34.2% less costly than previous middleware integration solution stack Crazy ROI!?
- 23. • Global, event-based systems • Eliminate bottlenecks in their systems • Wanted open-source solution • Faster time to market New Case Study: AMD and JBoss Fuse http://www.redhat.com/en/resources/amd-accelerates-time-market-red-hat-jboss-fuse
- 24. Why you should ride Camels too!
- 25. Real developers ride Camels!
- 26. • Community aspects • Anyone can become a committer • Run in whatever JVM container you want • Run in whatever Dependency Injection framework you want No “vendor lock in”
- 27. Integration Complexity Made Simple • Integrations of any Size and Complexity • Small investment to start • Extensible and reuse • Fast Path to Integration • Strong Unit Testing • OOTB Component Library
- 28. • Declarative • Uses existing developer tooling (eg, IDE) • Java, XML, Scala, Groovy, Kotlin Flexible, powerful DSL
- 29. Example: Java DSL public class OrderProcessorRouteBuilder extends RouteBuilder { @Override public void configure() throws Exception { from(“activemq:orders”) .choice() .when(header(“customer-rating”).isEqualTo(“gold”)) .to(“activemq:topic:specialCustomer”) .otherwise() .to(“sftp://user@host/orders/regularCustomers”) .end() .log(“received new order ${body.orderId}”) .to(“ibatis:storeOrder?statementType=Insert”); } }
- 30. • DSL for REST API • Out of the box Swagger integration • Powerful exception handling • Circuit breaker patterns Rapid REST APIs rest() .post(“/order/beer”) .description(“New order for a mug of beer”) .consumes(“application/json”) .route() .to(“activemq:topic:newOrder”) .log(“received new order ${body.orderId}”) .to(“ibatis:storeOrder?statementType=Insert”);
- 31. • JMX top to bottom • Codehale metrics • HawtIO web console • Fabric8 management Operational tooling
- 32. Demo
- 33. Data Integration
Editor's Notes
- We are going to talk about microservices, and all the goodness that buzzword entails… because you probably wouldn’t have joined this webinar with a few buzzwords… because a talk named something like “oh the same old service oriented architecture with camel” wasn’t as nifty of a title… Christian (25 Minutes): Slides 1-19 Intro (camel/opensource) as well as the competitive claims, as well as the new fuse tooling demo. Kenny (25 minutes): Slide 21-34 If you do the idc paper, amd ref and why camel/fuse is awesome slides plus whatever demo you want then we'll be good to go.
- For many years now we have been finding better ways to build systems. We have been learning from what has come before, adopting new technology, and observing how a new wave of technology companies operate in different ways to create IT systems that help make both their customers and own developers happier. Eric Evans’ Domain Driven Design helped us understand the importance of representing the real world in our code, and showed us a path towards better ways to model our systems. Continuous Delivery showed how we can more effectively and efficiently get our software into production, instilling in us the idea that we should treat every check in as a release candidate. Our understanding of how the Web works has led us to develop better ways of having machines talk to machines. Alistar Cockburn’s Hexagonal Architecture guided us away from layered architectures where business logic could hide. Virtualisation platforms allowed us to provision and resize our machines at will, with Infrastructure Automation giving us a way to handle these machines at scale. Some large, successful organisations like Amazon and Google espoused the view of small teams owning the full life-cycle of their services. And more recently Netflix has shared with us ways of building anti-fragile systems at a scale that would be hard to comprehend just ten years before. Domain Driven Design. Continuous Delivery. On-demand virtualisation. Infrastructure automation. Small autonomous teams. Systems at Scale. Microservices have emerged from this world. They weren’t invented or described before the fact, they emerged as a trend, or a pattern, from real-world use. But they only exist because of all that has gone before. I will pull strands out of this prior work to help paint a picture of how to build, manage and evolve Microservices throughout the rest of this book. Many organisations have found that by embracing fine-grained, microservice architectures, they can deliver software faster and embrace newer technologies. Microservices give us significantly more freedom to allow us to react and make different decisions, allowing us to react faster to the inevitable change that impacts all of us. Service-Oriented Architecture (SOA) is a design approach where multiple services collaborate together to provide some end set of capabilities. A service here typically means a completely separate operating system process. Communication between these services is done via calls across a network rather than method calls within a process boundary. SOA emerged as an approach to combat the challenges of the large monolithic applications. It is an approach which aims to promote the re-usability of software - two or more end-user applications for example could both use the same services. It is an approach which aims to make it easier to maintain or rewrite software, as theoretically we can replace one service with another without anyone knowing, as long as the semantics of the service don’t change too much. SOA at its heart is a very sensible idea. However, despite many efforts to the contrary, there is a lack of good consensus as how to do SOA well. In my opinion what much of the industry has failed to do is look holistically enough at the problem and present a compelling alternative to the narrative set out by various vendors in this space. Many of the problems lain at the door of SOA are actually problems with things like communication protocols (SOAP), vendor middle-ware, a lack of guidance about service granularity, or guidance on picking the wrong places to split your system. We’ll tackle each of these in turn throughout the rest of the book. A cynic might suggests that vendors co-opted (and in some cases drove) the SOA movement in a way to sell more products, and those self-same products in the end undermined the goal of SOA. Much of the conventional wisdom around SOA doesn’t help you understand how to split something big into something small. It doesn’t talk about how big is too big. It doesn’t talk enough about real-world practical ways to ensure that services do not become overly coupled. The number of things that go unsaid is where many of the pitfalls associated with SOA come from. The microservice approach has emerged from real-world use, taking our better understanding of systems and architecture on how to do SOA well. So you should instead think of Microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development.
- Communication is paramount!
- DSLs for Java, XML, OSGI, Groovy, Scala, Kotlin…highly polyglo
- Security Quality Customizations Support Documentation from the code No vendor lock in! There's another good advantage you missed. The ability to view the source code behind interfaces you are using gives you the absolute knowledge of the software's behavior with more certainty than any documentation could provide. http://revistaitnow.com/wp-content/uploads/2015/01/opensource.jpg 10 Reasons Open Source Is Good for Business With the many business and government organizations that now use open source software such as Linux, it's becoming increasingly clear that price is not the only advantage such software holds. If it were, companies that adopted it during the Great Recession would surely have switched back to the expensive proprietary stuff as soon as conditions began to ease, and that's clearly not the case. Rather, free and open source software (FOSS) holds numerous other compelling advantages for businesses, some of them even more valuable than the software's low price. Need a few examples? Let's start counting. 1. Security It's hard to think of a better testament to the superior security of open source software than the recent discovery by Coverity of a number of defects in the Android kernel. What's so encouraging about this discovery, as I noted the other day, is that the only reason it was possible is that the kernel code is open to public view. Android may not be fully open source, but the example is still a perfect illustration of what's known as "Linus' Law," named for Linus Torvalds, the creator of Linux. According to that maxim, "Given enough eyeballs, all bugs are shallow." What that means is that the more people who can see and test a set of code, the more likely any flaws will be caught and fixed quickly. It's essentially the polar opposite of the "security through obscurity" argument used so often to justify the use of expensive proprietary products, in other words. Does the absence of such flaw reports about the code of the iPhone or Windows mean that such products are more secure? Far from it--quite the opposite, you might even say. All it means is that those products are closed from public view, so no one outside the companies that own them has the faintest clue how many bugs they contain. And there's no way the limited set of developers and testers within those companies can test their products as well as the worldwide community constantly scrutinizing FOSS can. Bugs in open source software also tend to get fixed immediately, as in the case of the Linux kernel exploit uncovered not long ago. In the proprietary world? Not so much. Microsoft, for example, typically takes weeks if not months to patch vulnerabilities such as the recently discovered Internet Explorer zero-day flaw. Good luck to all the businesses using it in the meantime. 2. Quality Which is more likely to be better: a software package created by a handful of developers, or a software package created by thousands of developers? Just as there are countless developers and users working to improve the security of open source software, so are there just as many innovating new features and enhancements to those products. In general, open source software gets closest to what users want because those users can have a hand in making it so. It's not a matter of the vendor giving users what it thinks they want--users and developers make what they want, and they make it well. At least one recent study has shown, in fact, that technical superiority is typically the primary reason enterprises choose open source software. 3. Customizability Along similar lines, business users can take a piece of open source software and tweak it to suit their needs. Since the code is open, it's simply a matter of modifying it to add the functionality they want. Don't try that with proprietary software! 4. Freedom When businesses turn to open source software, they free themselves from the severe vendor lock-in that can afflict users of proprietary packages. Customers of such vendors are at the mercy of the vendor's vision, requirements, dictates, prices, priorities and timetable, and that limits what they can do with the products they're paying for. With FOSS, on the other hand, users are in control to make their own decisions and to do what they want with the software. They also have a worldwide community of developers and users at their disposal for help with that. 5. Flexibility When your business uses proprietary software such as Microsoft Windows and Office, you are on a treadmill that requires you to keep upgrading both software and hardware ad infinitum. Open source software, on the other hand, is typically much less resource-intensive, meaning that you can run it well even on older hardware. It's up to you--not some vendor--to decide when it's time to upgrade. 6. Interoperability Open source software is much better at adhering to open standards than proprietary software is. If you value interoperability with other businesses, computers and users, and don't want to be limited by proprietary data formats, open source software is definitely the way to go. 7. Auditability With closed source software, you have nothing but the vendor's claims telling you that they're keeping the software secure and adhering to standards, for example. It's basically a leap of faith. The visibility of the code behind open source software, however, means you can see for yourself and be confident. 8. Support Options Open source software is generally free, and so is a world of support through the vibrant communities surrounding each piece of software. Most every Linux distribution, for instance, has an online community with excellent documentation, forums, mailing lists, forges, wikis, newsgroups and even live support chat. For businesses that want extra assurance, there are now paid support options on most open source packages at prices that still fall far below what most proprietary vendors will charge. Providers of commercial support for open source software tend to be more responsive, too, since support is where their revenue is focused. 9. Cost Between the purchase price of the software itself, the exorbitant cost of mandatory virus protection, support charges, ongoing upgrade expenses and the costs associated with being locked in, proprietary software takes more out of your business than you probably even realize. And for what? You can get better quality at a fraction of the price. 10. Try Before You Buy If you're considering using open source software, it will typically cost you nothing to try it out first. This is partly due to the software's free price, and partly due to the existence of LiveCDs and Live USBs for many Linux distributions, for example. No commitment required until you're sure. None of this is to say, of course, that your business should necessarily use open source software for everything. But with all the many benefits it holds, you'd be remiss not to consider it seriously. Follow Katherine Noyes on Twitter: @Noyesk.
- However, what is not acceptable is that you market yourself as an open source product when in fact your business model is to sell closed source. This is confusing, I'd say it is border line lying. Well, marketing often is lying, but in the open source community we call out such lies, however subtle. While Andrew's intention with introducing the open core terminology may have been precisely to distinguish the practice from pure open source models, unfortunately the term is not used like that as far as I can tell. Most open core vendors still market themselves as open source leaders, then come to you to sell closed source software. (They deserve to be critizised if you ask me.) So if you ask me, we in the open source community should make it as difficult as possible for these companies to "get away with" their plans to take our software and make it closed source. We should openly criticize anyone who markets himself as open source but really just sells closed source software. As much as I like the fact that venture capital is flowing into open source companies, if all they want to do is take our software and make it closed source, then thanks, but no thanks. Free Software was not created to benefit venture capitalists, it was created to benefit and protect the freedoms of the users and developers of the software. We welcome them into our community if they want to join, but they are our guests. We should not let them get away with a plan based on taking a nice open source project and making it increasingly closed source. The final thing that I really don't like about the proliferation of open core is that mostly it is just lack of imagination and effort. It's like someone was put as a manager of an open source company, and after a while realizes selling is tough since most users choose not to pay. After some brainstorming you end up with "so let's just go back to selling closed source software". It just feels so lame, somehow, to me. http://openlife.cc/blogs/2010/june/open-core-not-open-source
- Too much code…
- Too many ways to hang yourself
- Lack of tooling…
- Doesn’t do all of what X ESB can do Camel is not an ESB. Pick the right tool for the job Not forced to buy entire suites, etc If your problem sounds like BPM, use BPM… not some half baked tool that tries to do too much. Tools that try to do too many things don’t do anything well Oh.. If you want to compare Camel to an EBS, then let’s be fair and compare an ESB to an ESB… eg, JBoss Fuse
- Camel/Fuse Strengths #1 Powerful DSL (pick when to use tooling, not limited to what you can do based on the tooling. DSL is very expressive and to the point; aids in the readability of integrations. Uses EIP patterns established by the EIP book (a direct implementation of the book) as opposed to each vendor’s re-invented nomenclature. Basically integrations are written far more than they’re written.