This document provides an agenda and summaries of key points from a presentation on integrating systems using Apache Camel. The presentation discusses how Apache Camel is an open-source integration library that uses enterprise integration patterns to connect disparate systems. It highlights features of Camel including components, data formats, and testing frameworks. Customer examples are presented that demonstrate large returns on investment and cost savings from using Camel for integration projects. The presenters argue that Camel provides flexibility, reusability and rapid development of integrations.
This document discusses integration in the age of DevOps. It describes how microservices help solve the problem of decoupling services and teams to move quickly at scale. Apache Camel is presented as a solution for integration that allows for reliable and distributed integration through mechanisms like messaging. Kubernetes and Docker are discussed as platforms that help develop and run microservices locally and at scale by providing automation, configuration, isolation and service discovery capabilities.
The document discusses Apache Camel, an open-source integration library that can be used to integrate disparate systems that use different protocols and data formats. It provides an overview of what integration is, describes how Camel works using a domain-specific language and components, and demonstrates how to define simple routes using Java or XML. The presentation concludes with information on management and tooling support for Camel.
This document provides an agenda and overview for a presentation on Apache Camel essential components. The presentation is given by Christian Posta from Red Hat on January 23, 2013. The agenda includes an introduction to Camel, a discussion of components, and time for questions. An overview of FuseSource/Red Hat is given, noting the acquisition of FuseSource by Red Hat in 2012. Details are provided on the speaker and their background. The document focuses on introducing some of the most widely used and essential Camel components, including File, Bean, Log, JMS, CXF, and Mock. Configuration options and examples of using each component are summarized.
Microservices with Apache Camel, Docker and Fabric8 v2Christian Posta
My talk from Red Hat Summit 2015 about the pros/cons of microservices, how integration is a strong requirement for doing distributed systems designs, and how open source projects like Apache Camel, Docker, Kubernetes, OpenShift and Fabric8 can help simplify and manage microservice environments
This document provides an overview of a presentation given at CamelOne 2013 in Boston on June 10-11, 2013 about the internals of Apache ActiveMQ. The presentation covered the major subcomponents of ActiveMQ including transports, the broker core, persistence adapters, and networking brokers. It provided details on architecture, configuration, and implementation of these different aspects of ActiveMQ.
This document provides an overview of Apache ActiveMQ, an open-source messaging server. It discusses ActiveMQ's features such as high performance, high availability, multiple protocols and transports. It also covers tools for benchmarking and performance tuning ActiveMQ brokers, including the ActiveMQ Performance Module, jms-benchmark, JMSTester, JMeter and OS monitoring tools. The document is intended to help understand how to approach performance tuning of ActiveMQ brokers.
Using apache camel for microservices and integration then deploying and managing on Docker and Kubernetes. When we need to make changes to our app, we can use Fabric8 continuous delivery built on top of Kubernetes and OpenShift.
This document discusses integration in the age of DevOps. It describes how microservices help solve the problem of decoupling services and teams to move quickly at scale. Apache Camel is presented as a solution for integration that allows for reliable and distributed integration through mechanisms like messaging. Kubernetes and Docker are discussed as platforms that help develop and run microservices locally and at scale by providing automation, configuration, isolation and service discovery capabilities.
The document discusses Apache Camel, an open-source integration library that can be used to integrate disparate systems that use different protocols and data formats. It provides an overview of what integration is, describes how Camel works using a domain-specific language and components, and demonstrates how to define simple routes using Java or XML. The presentation concludes with information on management and tooling support for Camel.
This document provides an agenda and overview for a presentation on Apache Camel essential components. The presentation is given by Christian Posta from Red Hat on January 23, 2013. The agenda includes an introduction to Camel, a discussion of components, and time for questions. An overview of FuseSource/Red Hat is given, noting the acquisition of FuseSource by Red Hat in 2012. Details are provided on the speaker and their background. The document focuses on introducing some of the most widely used and essential Camel components, including File, Bean, Log, JMS, CXF, and Mock. Configuration options and examples of using each component are summarized.
Microservices with Apache Camel, Docker and Fabric8 v2Christian Posta
My talk from Red Hat Summit 2015 about the pros/cons of microservices, how integration is a strong requirement for doing distributed systems designs, and how open source projects like Apache Camel, Docker, Kubernetes, OpenShift and Fabric8 can help simplify and manage microservice environments
This document provides an overview of a presentation given at CamelOne 2013 in Boston on June 10-11, 2013 about the internals of Apache ActiveMQ. The presentation covered the major subcomponents of ActiveMQ including transports, the broker core, persistence adapters, and networking brokers. It provided details on architecture, configuration, and implementation of these different aspects of ActiveMQ.
This document provides an overview of Apache ActiveMQ, an open-source messaging server. It discusses ActiveMQ's features such as high performance, high availability, multiple protocols and transports. It also covers tools for benchmarking and performance tuning ActiveMQ brokers, including the ActiveMQ Performance Module, jms-benchmark, JMSTester, JMeter and OS monitoring tools. The document is intended to help understand how to approach performance tuning of ActiveMQ brokers.
Using apache camel for microservices and integration then deploying and managing on Docker and Kubernetes. When we need to make changes to our app, we can use Fabric8 continuous delivery built on top of Kubernetes and OpenShift.
The document discusses continuous delivery of integration applications using JBoss Fuse and OpenShift. It covers the cost of change in software development, how JBoss Fuse can help with integration challenges, and how OpenShift enables continuous delivery through automation and a developer self-service platform as a service model. The presentation demonstrates how to build a continuous delivery pipeline using tools like Git, Jenkins, Fabric8, and OpenShift to deploy and test applications.
Microservices with Apache Camel, DDD, and KubernetesChristian Posta
Building microservices requires more than just infrastructure, but infrastructure does have a role. In this talk we look at microservices from an enterprise perspective and talk about DDD, Docker, Kubernetes and how established open-source projects in the integration space fits a microservices architecture
This document provides an overview and agenda for a presentation on Apache ActiveMQ 5.9.x and Apache Apollo. The presentation will cover new features in ActiveMQ 5.9.x including AMQP 1.0 support, REST management, a new default file-based store using LevelDB, and high availability replication of the store. It will also introduce Apache Apollo and allow for a question and discussion period.
This document provides an overview of integrating microservices with Apache Camel and JBoss Fuse. It introduces Apache Camel as a lightweight integration library that uses enterprise integration patterns and domain-specific languages to define integration "flows" and "routes". It describes how Camel supports features like dynamic routing, REST APIs, backpressure, load balancing, and circuit breakers that are useful for building microservices. The document also introduces JBoss Fuse as a development and runtime platform for microservices that provides tooling, frameworks, management capabilities and container support using technologies like Apache Camel, CXF, ActiveMQ and Karaf.
10 yrs ago, SOA promised a lot of the same things Microservices promise use today. So where did we go wrong? What makes microservices different? In this talk, we discussed from an architectural view how we went sideways with SOA, why we must embrace things like Domain Driven Design and scaled-out architectures, and how microservices can be built with enterprises in mind. We also cover a step-by-step, in-depth tutorial that covers these concepts.
Messaging is the backbone of many top enterprises. It affords reliable, asynchronous data passing to achieve loosely coupled, highly scalable distributed systems. As enterprises large and small become more interconnected, demand for remote and limited devices to be integrated with enterprise systems is surging. Come see how the most widely used, open-source messaging broker, Apache ActiveMQ, fits nicely and how it supports polyglot messaging.
Real-world #microservices with Apache Camel, Fabric8, and OpenShiftChristian Posta
What are and aren't microservices?
Microservices is a validation of the open-source approach to integration and service implementation and a rebuff of the committee-driven SOA approach. In this
Java one kubernetes, jenkins and microservicesChristian Posta
This document discusses microservices with Docker, Kubernetes and Jenkins. It provides an overview of Kubernetes concepts like pods, replication controllers, services and labels. It also discusses how Kubernetes can help manage containers across multiple hosts and address challenges of scaling, avoiding port conflicts and keeping containers running. The document promotes using Jenkins and Kubernetes for continuous integration and delivery of containerized microservices applications. It recommends Fabric8 as a tool that can help create and deploy microservices on Kubernetes.
The document discusses Christian Posta's journey with microservices architectures. It begins by explaining why organizations are moving to microservices and defines microservices. It then covers related topics like cloud platforms, container technologies like Kubernetes and OpenShift, benefits and drawbacks of microservices, and tools for developing microservices like Docker, Kubernetes, OpenShift, and Camel.
Cloud Development with Camel and Amazon Web ServicesRobin Howlett
This presentation will demonstrate how to rapidly prototype and develop distributed, scalable applications with Apache Camel, its AWS Components and the AWS Java SDK.
Robin Howlett is Senior Architect at Silver Chalice, a Chicago White Sox affiliated start-up, based in Boulder, CO, with a portfolio of high-value digital-based businesses in the fields of sports, media and entertainment. In 2011, he built the Advanced Media Platform, a proprietary cloud-based platform that services millions of requests per day across dozens of mobile application products, heavily utilizing the Apache Camel framework.
We consider a microservices architecture to achieve an end goal, not because it's "the cool thing to do". Every organization looking to adopt this architecture must realize (and adhere) to a set of foundational principles. Guided by those principles, we can correctly choose the technology to help support a microservices architecture and meet our end goals. This talk explains those core principles and gives you the tools needed for your microservices journey.
The document discusses microservices and APIs. It covers how microservices optimize for speed by shedding dependencies and having dependencies on demand through services and APIs. It discusses consumer contracts for APIs and service versioning. It also discusses using an API gateway pattern for scalability, security, monitoring and more. It promotes API management for benefits like access control, analytics, and monetization of microservices.
Flexible Permissions Management with ACL TemplatesJeff Potts
This is was presented as an ignite-style lightning talk at DevCon 2018 in Lisbon. It discusses an open source add-on called ACL Templates which can be used to separate ACL settings from code.
The Pivotal Engineering Dojo: Earning Your Black Belt in Cloud Foundry Engine...VMware Tanzu
This document summarizes Julz Friedman's experience earning a black belt in Cloud Foundry engineering through the CF dojo program. Some key points:
- Friedman spent 7-8 weeks at Pivotal's San Francisco office working with various CF teams to learn the codebase, build relationships, and gain credibility for themselves and IBM.
- The experience was overall positive and helped achieve the goals of understanding CF debugging, meeting team members, and contributing.
- Friedman paired with teams like Runtime, Bosh, Docs, and Services and observed differences between "big company agile" and Pivotal's XP-style approach.
- Lessons included embracing Pivotal's welcoming culture, the
Integrating Alfresco @ Scale (via event-driven micro-services)J V
Alfresco DevCon 2018 (Lisbon) - https://devcon.alfresco.com/
Alfresco provides a rich set of options for integrating third-party systems with services across the Digital Business Platform. We will deep-dive into the architecture of the new Alfresco Integration Services framework – a set of event-driven micro-services that can be easily deployed & scaled.
https://www.youtube.com/watch?v=TyB-t7wsDEE
Accessing the Alfresco repository from SharePoint is a big opportunity for some organizations who are looking to avoid to store everything in SharePoint and to centralize their documents in Alfresco. Taking the opportunity with the new version 1.1 of CMIS, we decided to build UI components on top of SharePoint using only common web technologies i.e. JS, HTML or CSS. The goal of these components is to be highly configurable and easy to customize depending of use cases.
Christian Posta is a principal middleware specialist and architect who has worked with large microservices architectures. He discusses why companies are moving to microservices and cloud platforms like Kubernetes and OpenShift. He covers characteristics of microservices like small autonomous teams and decentralized decision making. Posta also discusses breaking applications into independent services, shedding dependencies between teams, and using contracts and APIs for communication between services.
Microservices architecture is a very powerful way to build scalable systems optimized for speed of change. To do this, we need to build independent, autonomous services which by definition tend to minimize dependencies on other systems. One of the tenants of microservices, and a way to minimize dependencies, is “a service should own its own database”. Unfortunately this is a lot easier said than done. Why? Because: your data.
We’ve been dealing with data in information systems for 5 decades so isn’t this a solved problem? Yes and no. A lot of the lessons learned are still very relevant. Traditionally, we application developers have accepted the practice of using relational databases and relying on all of their safety guarantees without question. But as we build services architectures that span more than one database (by design, as with microservices), things get harder. If data about a customer changes in one database, how do we reconcile that with other databases (especially where the data storage may be heterogenous?).
For developers focused on the traditional enterprise, not only do we have to try to build fast-changing systems that are surrounded by legacy systems, the domains (finance, insurance, retail, etc) are incredibly complicated. Just copying with Netflix does for microservices may or may not be useful. So how do we develop and reason about the boundaries in our system to reduce complexity in the domain?
In this talk, we’ll explore these problems and see how Domain Driven Design helps grapple with the domain complexity. We’ll see how DDD concepts like Entities and Aggregates help reason about boundaries based on use cases and how transactions are affected. Once we can identify our transactional boundaries we can more carefully adjust our needs from the CAP theorem to scale out and achieve truly autonomous systems with strictly ordered eventual consistency. We’ll see how technologies like Apache Kafka, Apache Camel and Debezium.io can help build the backbone for these types of systems. We’ll even explore the details of a working example that brings all of this together.
The document discusses continuous delivery of integration applications using JBoss Fuse and OpenShift. It covers the cost of change in software development, how JBoss Fuse can help with integration challenges, and how OpenShift enables continuous delivery through automation and a developer self-service platform as a service model. The presentation demonstrates how to build a continuous delivery pipeline using tools like Git, Jenkins, Fabric8, and OpenShift to deploy and test applications.
Microservices with Apache Camel, DDD, and KubernetesChristian Posta
Building microservices requires more than just infrastructure, but infrastructure does have a role. In this talk we look at microservices from an enterprise perspective and talk about DDD, Docker, Kubernetes and how established open-source projects in the integration space fits a microservices architecture
This document provides an overview and agenda for a presentation on Apache ActiveMQ 5.9.x and Apache Apollo. The presentation will cover new features in ActiveMQ 5.9.x including AMQP 1.0 support, REST management, a new default file-based store using LevelDB, and high availability replication of the store. It will also introduce Apache Apollo and allow for a question and discussion period.
This document provides an overview of integrating microservices with Apache Camel and JBoss Fuse. It introduces Apache Camel as a lightweight integration library that uses enterprise integration patterns and domain-specific languages to define integration "flows" and "routes". It describes how Camel supports features like dynamic routing, REST APIs, backpressure, load balancing, and circuit breakers that are useful for building microservices. The document also introduces JBoss Fuse as a development and runtime platform for microservices that provides tooling, frameworks, management capabilities and container support using technologies like Apache Camel, CXF, ActiveMQ and Karaf.
10 yrs ago, SOA promised a lot of the same things Microservices promise use today. So where did we go wrong? What makes microservices different? In this talk, we discussed from an architectural view how we went sideways with SOA, why we must embrace things like Domain Driven Design and scaled-out architectures, and how microservices can be built with enterprises in mind. We also cover a step-by-step, in-depth tutorial that covers these concepts.
Messaging is the backbone of many top enterprises. It affords reliable, asynchronous data passing to achieve loosely coupled, highly scalable distributed systems. As enterprises large and small become more interconnected, demand for remote and limited devices to be integrated with enterprise systems is surging. Come see how the most widely used, open-source messaging broker, Apache ActiveMQ, fits nicely and how it supports polyglot messaging.
Real-world #microservices with Apache Camel, Fabric8, and OpenShiftChristian Posta
What are and aren't microservices?
Microservices is a validation of the open-source approach to integration and service implementation and a rebuff of the committee-driven SOA approach. In this
Java one kubernetes, jenkins and microservicesChristian Posta
This document discusses microservices with Docker, Kubernetes and Jenkins. It provides an overview of Kubernetes concepts like pods, replication controllers, services and labels. It also discusses how Kubernetes can help manage containers across multiple hosts and address challenges of scaling, avoiding port conflicts and keeping containers running. The document promotes using Jenkins and Kubernetes for continuous integration and delivery of containerized microservices applications. It recommends Fabric8 as a tool that can help create and deploy microservices on Kubernetes.
The document discusses Christian Posta's journey with microservices architectures. It begins by explaining why organizations are moving to microservices and defines microservices. It then covers related topics like cloud platforms, container technologies like Kubernetes and OpenShift, benefits and drawbacks of microservices, and tools for developing microservices like Docker, Kubernetes, OpenShift, and Camel.
Cloud Development with Camel and Amazon Web ServicesRobin Howlett
This presentation will demonstrate how to rapidly prototype and develop distributed, scalable applications with Apache Camel, its AWS Components and the AWS Java SDK.
Robin Howlett is Senior Architect at Silver Chalice, a Chicago White Sox affiliated start-up, based in Boulder, CO, with a portfolio of high-value digital-based businesses in the fields of sports, media and entertainment. In 2011, he built the Advanced Media Platform, a proprietary cloud-based platform that services millions of requests per day across dozens of mobile application products, heavily utilizing the Apache Camel framework.
We consider a microservices architecture to achieve an end goal, not because it's "the cool thing to do". Every organization looking to adopt this architecture must realize (and adhere) to a set of foundational principles. Guided by those principles, we can correctly choose the technology to help support a microservices architecture and meet our end goals. This talk explains those core principles and gives you the tools needed for your microservices journey.
The document discusses microservices and APIs. It covers how microservices optimize for speed by shedding dependencies and having dependencies on demand through services and APIs. It discusses consumer contracts for APIs and service versioning. It also discusses using an API gateway pattern for scalability, security, monitoring and more. It promotes API management for benefits like access control, analytics, and monetization of microservices.
Flexible Permissions Management with ACL TemplatesJeff Potts
This is was presented as an ignite-style lightning talk at DevCon 2018 in Lisbon. It discusses an open source add-on called ACL Templates which can be used to separate ACL settings from code.
The Pivotal Engineering Dojo: Earning Your Black Belt in Cloud Foundry Engine...VMware Tanzu
This document summarizes Julz Friedman's experience earning a black belt in Cloud Foundry engineering through the CF dojo program. Some key points:
- Friedman spent 7-8 weeks at Pivotal's San Francisco office working with various CF teams to learn the codebase, build relationships, and gain credibility for themselves and IBM.
- The experience was overall positive and helped achieve the goals of understanding CF debugging, meeting team members, and contributing.
- Friedman paired with teams like Runtime, Bosh, Docs, and Services and observed differences between "big company agile" and Pivotal's XP-style approach.
- Lessons included embracing Pivotal's welcoming culture, the
Integrating Alfresco @ Scale (via event-driven micro-services)J V
Alfresco DevCon 2018 (Lisbon) - https://devcon.alfresco.com/
Alfresco provides a rich set of options for integrating third-party systems with services across the Digital Business Platform. We will deep-dive into the architecture of the new Alfresco Integration Services framework – a set of event-driven micro-services that can be easily deployed & scaled.
https://www.youtube.com/watch?v=TyB-t7wsDEE
Accessing the Alfresco repository from SharePoint is a big opportunity for some organizations who are looking to avoid to store everything in SharePoint and to centralize their documents in Alfresco. Taking the opportunity with the new version 1.1 of CMIS, we decided to build UI components on top of SharePoint using only common web technologies i.e. JS, HTML or CSS. The goal of these components is to be highly configurable and easy to customize depending of use cases.
Christian Posta is a principal middleware specialist and architect who has worked with large microservices architectures. He discusses why companies are moving to microservices and cloud platforms like Kubernetes and OpenShift. He covers characteristics of microservices like small autonomous teams and decentralized decision making. Posta also discusses breaking applications into independent services, shedding dependencies between teams, and using contracts and APIs for communication between services.
Microservices architecture is a very powerful way to build scalable systems optimized for speed of change. To do this, we need to build independent, autonomous services which by definition tend to minimize dependencies on other systems. One of the tenants of microservices, and a way to minimize dependencies, is “a service should own its own database”. Unfortunately this is a lot easier said than done. Why? Because: your data.
We’ve been dealing with data in information systems for 5 decades so isn’t this a solved problem? Yes and no. A lot of the lessons learned are still very relevant. Traditionally, we application developers have accepted the practice of using relational databases and relying on all of their safety guarantees without question. But as we build services architectures that span more than one database (by design, as with microservices), things get harder. If data about a customer changes in one database, how do we reconcile that with other databases (especially where the data storage may be heterogenous?).
For developers focused on the traditional enterprise, not only do we have to try to build fast-changing systems that are surrounded by legacy systems, the domains (finance, insurance, retail, etc) are incredibly complicated. Just copying with Netflix does for microservices may or may not be useful. So how do we develop and reason about the boundaries in our system to reduce complexity in the domain?
In this talk, we’ll explore these problems and see how Domain Driven Design helps grapple with the domain complexity. We’ll see how DDD concepts like Entities and Aggregates help reason about boundaries based on use cases and how transactions are affected. Once we can identify our transactional boundaries we can more carefully adjust our needs from the CAP theorem to scale out and achieve truly autonomous systems with strictly ordered eventual consistency. We’ll see how technologies like Apache Kafka, Apache Camel and Debezium.io can help build the backbone for these types of systems. We’ll even explore the details of a working example that brings all of this together.
Microservices, DevOps, and Containers with OpenShift and Fabric8Christian Posta
The document discusses microservices, DevOps, and containers. It introduces the speaker, Christian Posta, and his background working with microservices at a large company. It then asks questions about the organization's motivations for considering microservices and discusses challenges with keeping up with change. The document promotes OpenShift and Fabric8 as open-source platforms that can help automate build, deployment, and integration processes in a cloud-native way. It highlights features like CI/CD, management tools, and libraries to simplify developing microservices applications.
Real world #microservices with Apache Camel, Fabric8, and OpenShiftChristian Posta
What are, or aren't, microservices?
There's a lot of hype and buzz, but microservices emerged organically vs how some of the other distributed architectural styles were "handed down to us", so I believe there's some good things once you cut through the hype. In this talk I discussed what are and are NOT microservices, introduced some concepts, and discussed some concrete open-source libraries and frameworks that can help you develop and manage microservice style deployments.
JavaOne 2016: Kubernetes introduction for Java Developers Rafael Benevides
This document provides an introduction to Kubernetes and summarizes some of its key concepts. It describes how Kubernetes can manage containers across multiple machines and help address challenges of scaling, port conflicts, and high availability. Core Kubernetes concepts discussed include pods, replication controllers, labels, services, and persistent volumes. It also provides an overview of a sample application that will be used in an accompanying Kubernetes lab.
Single tenant software to multi-tenant SaaS using K8SCloudLinux
This document discusses how Kubernetes can be used to convert single-tenant software applications into multi-tenant SaaS applications. Key points include:
1) Kubernetes can orchestrate each tenant as a separate pod or set of pods, providing isolation, easy scalability, and the ability to customize deployments for each tenant.
2) This approach simplifies many challenges of traditional SaaS like customer management, billing integration, high availability, upgrades and rollbacks by leveraging Kubernetes features.
3) An initial test project converted an existing PHP/MySQL billing application for 10,000+ companies into a multi-tenant SaaS deployment using Kubernetes, requiring under 40 hours of development.
Multi tier, multi-tenant, multi-problem kafkaTodd Palino
At LinkedIn, the Kafka infrastructure is run as a service: the Streaming team develops and deploys Kafka, but is not the producer or consumer of the data that flows through it. With multiple datacenters, and numerous applications sharing these clusters, we have developed an architecture with multiple pipelines and multiple tiers. Most days, this works out well, but it has led to many interesting problems. Over the years we have worked to develop a number of solutions, most of them open source, to make it possible for us to reliably handle over a trillion messages a day.
Securing MongoDB to Serve an AWS-Based, Multi-Tenant, Security-Fanatic SaaS A...MongoDB
MongoDB introduces new capabilities that change the way micro-services interact with the database, capabilities that are either absent or exist only partially in high-end commercial databases such as Oracle. In this session I will share from my experiences building a cloud-based, multi-tenant SaaS application with extreme security requirements. We will cover topics including considerations for storing multi-tenant data in the database, best practices for authentication and authorization, and performance considerations specific to security in MongoDB.
Or how I learned to stop worrying and love Continuous Deployment...
Presentation by Tom Wilkie on 29/09/16 at SF Microservices Meetup.
In this talk I discuss the journey Weaveworks has been through building Weave Cloud, using all the laster buzzword-compliant techniques: Microservices, DevOps, Continuous Delivery, Kubernetes, Docker etc.
Sitecore development approach evolution – destination helixPeter Nazarov
Sitecore Development Approach Evolution – Destination Helix
Sitecore officially recommended Helix as a set of overall design principles and conventions for Sitecore development around 18 month ago at SUGCON 2016 alongside with an official implementation example - Habitat. Why was it necessary? What are the benefits? Has it worked in practice? Peter Nazarov will share the outlook on why and how a combination of Sitecore Helix and Habitat benefits the business and development users of Sitecore in practice.
Measure and Increase Developer Productivity with Help of Serverless at JCON 2...Vadym Kazulkin
The goal of Serverless is to focus on writing the code that delivers business value and offload everything else to your trusted partners (like Cloud providers or SaaS vendors). You want to iterate quickly and today’s code quickly becomes tomorrow’s technical debt. In this talk we will show why Serverless adoption increases the developer productivity and how to measure it. We will also go through AWS Serverless architectures where you only glue together different Serverless managed services relying solely on configuration, minimizing the amount of the code written.
"It’s not only Lambda! Economics behind Serverless" at JAX Conference in Mai ...Vadym Kazulkin
When we talk about prices, we often only talk about Lambda costs. But we rarey use only Lambda in our applications. Usually, we have other building blocks like API Gateway, data sources like SNS, SQS or Kinesis and Log service (Cloud Watch). Also, we store our data either in S3 or in serverless databases like DynamoDB or recently in Aurora Serverless. All these services have their own price models which we have to pay attention to. Moreover, we have to consider application data transfer costs. In this talk, we will draw the complete picture about the costs in the serverless applications, look at the Total Cost of Ownership and make some recommendations about when it’s worth using serverless and when the traditional approach (EC2)
"It’s not only Lambda! Economics behind Serverless" at Serverless Architectur...Vadym Kazulkin
When we talk about prices, we often only talk about Lambda costs. But we rarey use only Lambda in our applications. Usually, we have other building blocks like API Gateway, data sources like SNS, SQS or Kinesis and Log service (Cloud Watch). Also, we store our data either in S3 or in serverless databases like DynamoDB or recently in Aurora Serverless. All these services have their own price models which we have to pay attention to. Moreover, we have to consider application data transfer costs. In this talk, we will draw the complete picture about the costs in the serverless applications, look at the Total Cost of Ownership and make some recommendations about when it’s worth using serverless and when the traditional approach (EC2)
Convince your boss to go Serverless at serverless week BrazilVadym Kazulkin
TCO of Serverless application. How Serverless helps us to be productive, write less code and implement evolutionary architectures. How to measure productivity to see you're on track with Serverless
The document discusses the Apache SOA stack and debunks some myths about SOA. It provides an overview of the Enterprise Service Bus (ESB) and explains why the Apache ServiceMix stack is a good choice as an ESB due to its modularity, stability, and cluster capabilities. The document also discusses how to design software and build systems for an ESB using OSGi and Maven.
Lino Telera gave a presentation on serverless computing. He began with introductions and background. The presentation covered serverless concepts like Function as a Service, demonstrated building a simple microservice using AWS Lambda that interacts with S3, and discussed integrating functions with services like S3 using Boto. It also showed how functions can be called from devices using skills and discussed running serverless on-premise using OpenFaaS or Pivotal Container Service. The presentation concluded with a Q&A and thanks to sponsors.
A presentation on why or why not microservices, why a platform is important, discovering how to break down a monolith and some of the challenges you'll face (data, transactions, boundaries, etc). Last section is on Istio and service mesh introductions. Follow on twitter @christianposta for updates and more details
Measure and increase developer productivity with help of Severless by Kazulki...Vadym Kazulkin
The goal of Serverless is to focus on writing the code that delivers business value and offload everything else to your trusted partners (like Cloud providers or SaaS vendors). You want to iterate quickly and today’s code quickly becomes tomorrow’s technical debt. In this talk we will show why Serverless adoption increases the developer productivity and how to measure it. We will also go through AWS Serverless architectures where you only glue together different Serverless managed services relying solely on configuration, minimizing the amount of the code written.
Containers, microservices and serverless for realistsKarthik Gaekwad
The document discusses containers, microservices, and serverless applications for developers. It provides an overview of these topics, including how containers and microservices fit into the DevOps paradigm and allow for better collaboration between development and operations teams. It also discusses trends in container usage and orchestration as well as differences between platforms as a service (PaaS) and serverless applications.
The document discusses strategies for transitioning from monolithic architectures to microservice architectures. It outlines some of the challenges with maintaining large monolithic applications and reasons for modernizing, such as handling more data and needing faster changes. It then covers microservice design principles and best practices, including service decomposition, distributed systems strategies, and reactive design. Finally it introduces Lagom as a framework for building reactive microservices on the JVM and outlines its key components and development environment.
Deep Dive Into Elasticsearch: Establish A Powerful Log Analysis System With E...Tyler Nguyen
We will have a deep view of the Elastic Stack - which is the next evolution of ELK Stack, learn how to build the powerful log analysis system with Elastic Stack and have an overview of specifications and comparison details between the self-managed cluster vs Elastic stack provided as SaaS from cloud providers.
This document discusses ideas and technologies for building scalable software systems and processing big data. It covers:
1. Bi-modal distribution of developers shapes architecture/design and the need for loosely/tightly coupled code.
2. Internet companies like Google and Facebook innovate at large scale using open source tools and REST architectures.
3. A REST architecture allows scalability, extensible development, and integration of tools/ideas from the internet for non-internet applications.
FoundationDB is a next-generation database that aims to provide high performance transactions at massive scale through a distributed design. It addresses limitations of NoSQL databases by providing a transactional, fault-tolerant foundation using tools like the Flow programming language. FoundationDB has demonstrated high performance that exceeds other NoSQL databases, and provides ease of scaling, building abstractions, and operation through its transactional design and automated partitioning. The goal is to solve challenges of state management so developers can focus on building applications.
Rami Sayar - Node microservices with DockerWeb à Québec
The document discusses converting a monolithic Node.js application into microservices and deploying them using Docker. It begins by defining microservices and their benefits. It then describes converting a sample pizza ordering application into independent microservices for handling messages, serving the frontend, and providing an API. Next, it covers patterns for networking microservices, including using an API gateway. It concludes by demonstrating how to deploy the microservices to Docker containers and use an orchestration tool like Kubernetes to manage them.
Software Architecture and Architectors: useless VS valuableComsysto Reply GmbH
The document discusses several cases where architecture decisions hurt software teams. It provides lessons learned from each case:
- Overly sharing code across domains can cause dependencies and fragility. Architectural boundaries should separate domains.
- Attempting to satisfy all use cases with a single highly configurable solution often satisfies no one. Specific solutions may be preferable.
- Microservices are not a universal solution and will not improve a flawed design alone. Modules should only be split across microservices at domain boundaries.
- Systems need to be designed to evolve dynamically over time as requirements change. Centralized control hinders this.
Stay productive while slicing up the monolith Markus Eisele
DevNexus 2017
Microservices-based architectures are en-vogue. The last couple of
years we have learned how the thought-leaders implement them, and
every other week we have heard about how containers and
Platform-as-a-Service offerings make them ultimately happen.
The problem is that the developers are almost forgotten and left alone
with provisioning and continuous delivery systems, containers and
resource schedulers, and frameworks and patterns to help slice
existing monoliths. How can we get back in control and efficiently
develop them without having to provision complete production-like
environments locally, by hand?
All the new buzzwords, frameworks, and hyped tools have made us forget
ourselves—Java developers–and what it means to be productive and have
fun building systems. The problem that we set out to solve is: how can
we run real-world Microservices-based systems on our local development
machines, managing provisioning, and orchestration of potentially
hundreds of services directly from a single command line tool, without
sacrificing productivity enablers like hot code reloading and instant
turnaround time?
During this talk, you’ll experience first-hand how much fun it can be
to develop large-scale Microservices-based systems. You will learn a
lot about what it takes to fail fast and recover and truly understand
the power of a fully integrated Microservices development environment.
The document discusses visual analysis using Google Cloud Platform. It provides an overview of Google Cloud services including App Engine, Container Engine, Compute Engine, Datastore, Cloud SQL, and Spanner for building and deploying applications at scale. It also mentions Machine Learning services for tasks like natural language processing, image analysis, and translation. The presentation then demonstrates a photo sharing application built on these services and discusses ways to enhance it further using App Engine Flex, video processing, document parsing, BigQuery, and analytics. It concludes by inviting Python developers interested in visual analysis to discuss job opportunities.
Similar to Why real integration developers ride Camels (20)
Move Auth, Policy, and Resilience to the PlatformChristian Posta
Developer's time is the most crucial resource in an enterprise IT organization. Too much time is spent on undifferentiated heavy lifting and in the world of APIs and microservices much of that is spent on non-functional, cross-cutting networking requirements like security, observability, and resilience.
As organizations reconcile their DevOps practices into Platform Engineering, tools like Istio help alleviate developer pain. In this talk we dig into what that pain looks like, how much it costs, and how Istio has solved these concerns by examining three real-life use cases. As this space continues to emerge, and innovation has not slowed, we will also discuss the recently announced Istio sidecar-less mode which significantly reduces the hurdles to adopt Istio within Kubernetes or outside Kubernetes.
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
Service mesh is a powerful pattern for implementing strong zero-trust networking practices, introducing better network observability, and allowing for more fine-grained traffic control. Up until now, the sidecar pattern was used to implement service-mesh capability but as the technology matures, a new pattern has emerged: sidecarless service mesh. Two prominent open-source networking projects, Cilium and Istio, have implemented a sidecar-free approach to service mesh but they both make interesting design decisions and tradeoffs. In this talk we review the architecture of both, focusing on the pros and cons of implementations such as mutual authentication, ingress, and observability.
Understanding Wireguard, TLS and Workload IdentityChristian Posta
Zero Trust Networking has become a standard marketing buzzword but the underlying principles are critical for modern microservice-style architectures. Authentication, authorizations, policy, etc. can be difficult to implement between services and do so in a maintainable way. Google invented their own transparent encryption and authorization protocol called "ALTS" back in 2007 to serve the application layer of Google's Borg workload scheduler, but we don't see others using it outside Google.
In this webinar we look at existing technology like TLS and newcomer Wireguard and see how these technologies come together to provide a secure foundation for workload identity and modern service-to-service networking.
Istio ambient mesh uses a sidecar-less data plane that focuses on ease of operations, incremental adoption, and separation of security boundaries for applications and mesh infrastructure.
In this webinar, we'll explore:
- The forces of modernization and compliance pressures,
- How Zero Trust Architecture (ZTA) can help, and
- How Istio ambient mesh lowers the barrier for establishing the properties necessary to achieve Zero Trust and compliance
The document discusses Cilium and Istio with Gloo Mesh. It provides an overview of Gloo Mesh, an enterprise service mesh for multi-cluster, cross-cluster and hybrid environments based on upstream Istio. Gloo Mesh focuses on ease of use, powerful best practices built in, security, and extensibility. It allows for consistent API for multi-cluster north-south and east-west policy, team tenancy with service mesh as a service, and driving everything through GitOps.
This document discusses service mesh patterns for connecting microservices across multiple clusters. It describes using Envoy proxy to provide service discovery, load balancing, security and resiliency. Patterns are presented for connecting services across clusters with flat, controlled or separate networks. Managing connectivity across clusters can increase operator burden. Gloo Mesh is presented as a way to simplify management across multiple clusters with a centralized control plane.
Multicluster Kubernetes and Service Mesh PatternsChristian Posta
Building applications for cloud-native infrastructure that are resilient, scalable, secure, and meet compliance and IT objectives gets complicated. Another wrinkle for the organizations with which we work is the fact they need to run across a hybrid deployment footprint, not just Kubernetes. At Solo.io, we build application networking technology on Envoy Proxy that helps solve difficult multi-deployment, multi-cluster, and even multi-mesh problems.
In this webinar, we’re going to explore different options and patterns for building secure, scalable, resilient applications using technology like Kubernetes and Service Mesh without leaving behind existing IT investments. We’ll see why and when to use multi-cluster topologies, how to build for high availability and team autonomy, and solve for things like service discovery, identity federation, traffic routing, and access control.
Cloud-Native Application Debugging with Envoy and Service MeshChristian Posta
Microservices have been great for accelerating the software innovation and delivery, but they also present new challenges, especially as abstractions and automated orchestration at every layer make pinpointing the issue seem like walking around a maze with a blindfold. Existing tools weren’t designed for distributed environments, and the new tools need to consider how to leverage these abstraction layers to better observe, test, and troubleshoot issues.
Christian Posta walks you through Envoy Proxy and service mesh architecture for L7 data plane, the key features in Envoy that can help in debugging and troubleshooting, chaos engineering as a testing methodology for microservices, how to approach a testing and debugging framework for microservices, and new open source tools that address these areas. You’ll explore a workflow to discover and resolve microservices issues, including injecting experiments for stress testing the applications, gathering requests in flight, recording and replaying them, and debugging them step by step without affecting production traffic.
Kubernetes Ingress to Service Mesh (and beyond!)Christian Posta
Kubernetes users need to allow traffic to flow into and within the cluster. Treating the application traffic separately from the business logic allows presents new possibilities in how service to service traffic is served, controlled and observed — and provides a transition to intra cluster networking like Service Mesh. With microservices, there is a concept of both North / South traffic (incoming requests from end users to the cluster) and East / West (intra cluster) communication between the services. In this talk we will explain how Envoy Proxy works in Kubernetes as a proxy for both of these traffic directions and how it can be leveraged to do things like traffic shaping, security, and integrate the north/south to east/west behavior.
Christian Posta (@christianposta) is Global Field CTO at Solo.io, former Chief Architect at Red Hat, and well known in the community for being an author (Istio in Action, Manning, Istio Service Mesh, O'Reilly 2018, Microservices for Java Developers, O’Reilly 2016), frequent blogger, speaker, open-source enthusiast and committer on various open-source projects including Istio, Kubernetes, and many others. Christian has spent time at both enterprises as well as web-scale companies and now helps companies create and deploy large-scale, cloud-native resilient, distributed architectures. He enjoys mentoring, training and leading teams to be successful with distributed systems concepts, microservices, devops, and cloud-native application design.
The exploration of service mesh for any organization comes with some serious questions. What data plane should I use? How does this tie in with my existing API infrastructure? What kind of overhead do sidecar proxies demand? As I've seen in my work with various organizations over the years "if you have a successful microservices deployment, then you have a service mesh whether it’s explicitly optimized as one or not."
In this talk, we seek to understand the role of the data plane and how to pick the right component for the problem context. We start off by establishing the spectrum of data-plane components from shared gateways to in-code libraries with service proxies being along that spectrum. We clearly identify which scenarios would benefit from which part of the data-plane spectrum and show how modern service meshes including Istio, Linkerd, and Consul enable these optimizations.
Deep Dive: Building external auth plugins for Gloo EnterpriseChristian Posta
Using the plugin framework for Ext. Auth Service in Gloo Enterprise, we can build any custom AuthN/AuthZ plugins to handle security requirements not provided out of the box.
Role of edge gateways in relation to service mesh adoptionChristian Posta
API Gateways provide functionality like rate limiting, authentication, request routing, reporting, and more. If you’ve been following the rise in service-mesh technologies, you’ll notice there is a lot of overlap with API Gateways when solving some of the challenges of microservices. If service mesh can solve these same problems, you may wonder whether you really need a dedicated API Gateway solution?
The reality is there is some nuance in the problems solved at the edge (API Gateway) compared to service-to-service communication (service mesh) within a cluster. But with the evolution of cluster-deployment patterns, these nuances are becoming less important. What’s more important is that the API Gateway is evolving to live at a layer above service mesh and not directly overlapping with it. In other words, API Gateways are evolving to solve application-level concerns like aggregation, transformation, and deeper context and content-based routing as well as fitting into a more self-service, GitOps style workflow.
In this talk we put aside the “API Gateway” infrastructure as we know it today and go back to first principles with the “API Gateway pattern” and revisit the real problems we’re trying to solve. Then we’ll discuss pros and cons of alternative ways to implement the API Gateway pattern and finally look at open source projects like Envoy, Kubernetes, and GraphQL to see how the “API Gateway pattern” actually becomes the API for our applications while coexisting nicely with a service mesh (if you adopt a service mesh).
Navigating the service mesh landscape with Istio, Consul Connect, and LinkerdChristian Posta
The document discusses various service mesh options including Linkerd, Consul Connect, Istio, and AWS App Mesh. It provides an overview of each solution, describing their key features and strengths/opportunities. It emphasizes that the service mesh approach is useful for managing inter-service communication and that implementations are still evolving. It recommends starting simply and iteratively adopting capabilities to match needs.
Distributed microservices introduce new challenges: failure modes are harder to anticipate and resolve. In this session, we present a “Chaos Debugging” framework enabled by three open source projects: Gloo Shot, Squash, and Loop to help you increase your microservices’ “immunity” to issues.
Gloo Shot integrates with any service mesh to implement advanced, realistic chaos experiments. Squash connects powerful and mature debuggers (gdb, dlv, java debugging) to your microservices while they run in Kubernetes. Loop extends the capability of your service mesh to observe your application and record full transactions for sandboxed replay and debugging.
Come to this demo-heavy talk to see how together, Squash, Gloo Shot, and Loop allow you to trigger, replay, and investigate failure modes of your microservices in a language agnostic and efficient manner without requiring any changes to your code.
Leveraging Envoy Proxy and GraphQL to Lower the Risk of Monolith to Microserv...Christian Posta
If you have an existing Java monolith, you know you must take care making changes to it or altering it in any negative way. Often times these monoliths are very valuable to the business and generate a lot of revenue. At the same time, since it’s difficult to make changes to the monolith it’s desirable to move to a microservices architecture. Unfortunately you cannot just do a big-bang migration to a greenfield architecture and will have to incrementally adopt microservices. In this talk, we’ll look at using Gloo proxy which is based on Envoy Proxy and GraphQL to do surgical, function-level traffic control and API aggregation to safely migrate your monolith to microservices and serverless functions.
Service-mesh options with Linkerd, Consul, Istio and AWS AppMeshChristian Posta
Service mesh abstracts the network from developers to solve three main pain points:
How do services communicate securely with one another
How can services implement network resilience
When things go wrong, can we identify what and why
Service mesh implementations usually follow a similar architecture: traffic flows through control points between services (usually service proxies deployed as sidecar processes) while an out-of-band set of nodes is responsible for defining the behavior and management of the control points. This loosely breaks out into an architecture of a "data plane" through which requests flow and a "control plane" for managing a service mesh.
Different service mesh implementations use different data planes depending on their use cases and familiarity with particular technology. The control plane implementations vary between service-mesh implementations as well. In this talk, we'll take a look at three different control plane implementations with Istio, Linkerd and Consul, their strengths, and their specific tradeoffs to see how they chose to solve each of the three pain points from above. We can use this information to make choices about a service mesh or to inform our journey if we choose to build a control plane ourselves.
The document summarizes the new features of Istio 1.1, an open-source service mesh. Some key highlights include improved performance and scalability, namespace isolation, multi-cluster capabilities, easier installation with Helm, and locality-aware load balancing. A new Sidecar resource was introduced to improve performance by configuring resources for individual proxies. The presentation demonstrates performance improvements with the Sidecar resource and highlights additional functionality in Istio like traffic control and metrics collection.
API Gateways are going through an identity crisisChristian Posta
API Gateways provide functionality like rate limiting, authentication, request routing, reporting, and more. If you've been following the rise in service-mesh technologies, you'll notice there is a lot of overlap with API Gateways when solving some of the challenges of microservices. If service mesh can solve these same problems, you may wonder whether you really need a dedicated API Gateway solution?
The reality is there is some nuance in the problems solved at the edge (API Gateway) compared to service-to-service communication (service mesh) within a cluster. But with the evolution of cluster-deployment patterns, these nuances are becoming less important. What's more important is that the API Gateway is evolving to live at a layer above service mesh and not directly overlapping with it. In other words, API Gateways are evolving to solve application-level concerns like aggregation, transformation, and deeper context and content-based routing as well as fitting into a more self-service, GitOps style workflow.
In this talk we put aside the "API Gateway" infrastructure as we know it today and go back to first principles with the "API Gateway pattern" and revisit the real problems we're trying to solve. Then we'll discuss pros and cons of alternative ways to implement the API Gateway pattern and finally look at open source projects like Envoy, Kubernetes, and GraphQL to see how the "API Gateway pattern" actually becomes the API for our applications while coexisting nicely with a service mesh (if you adopt a service mesh).
KubeCon NA 2018: Evolution of Integration and Microservices with Service Mesh...Christian Posta
Cloud-native describes a way of building applications on a cloud platform to iteratively discover and deliver business value. We now have access to a lot of similar technology that the large internet companies pioneered and used to their advantage to dominate their respective markets. What challenges arise when we start building applications to take advantage of this new technology?
In this talk we'll explore the role of service meshes when building distributed systems, why they make sense, and where they don't make sense. We will look at a class of problem that crops up that service mesh cannot solve, but that frameworks and even new programming languages like Ballerina are aiming to solve
Service-mesh technology promises to deliver a lot of value to a cloud-native application, but it doesn't come without some hype. In this talk, we'll look at what is a "service mesh", how it compares to similar technology (Netflix OSS, API Management, ESBs, etc) and what options for service mesh exist today.
Navigating the New Era of Adaptive PPM with OnePlan - Webinar 27Jun24.pdfOnePlan Solutions
The landscape of Project Portfolio Management (PPM) is undergoing a significant transformation, driven by the need for more adaptive, responsive approaches to managing projects and portfolios in a rapidly changing business environment. This evolution calls for tools and methodologies that can support dynamic decision-making, flexible resource allocation, and real-time strategic alignment.
Join us as we delve into how OnePlan emerges as a pivotal solution in this new era. Discover how OnePlan empowers organizations to navigate complexity and embrace change effectively, ensuring project success and strategic alignment. Learn how OnePlan enhances the capabilities of the tools your organization has already invested in, breaking down data silos and providing a unified view of project information.
What is OCR Technology and How to Extract Text from Any Image for FreeTwisterTools
Discover the fascinating world of Optical Character Recognition (OCR) technology with our comprehensive presentation. Learn how OCR converts various types of documents, such as scanned paper documents, PDFs, or images captured by a digital camera, into editable and searchable data. Dive into the history, modern applications, and future trends of OCR technology. Get step-by-step instructions on how to extract text from any image online for free using a simple tool, along with best practices for OCR image preparation. Ideal for professionals, students, and tech enthusiasts looking to harness the power of OCR.
In this session, developers explored CBWIRE, a ColdBox module that simplifies modern, reactive CFML app development without JavaScript frameworks like Vue or React. Attendees learned its usage, benefits, and the new features introduced in CBWIRE version 4, designed based on community feedback. The session catered to developers familiar with ColdBox and CFML, offering practical insights and guidance for leveraging CBWIRE effectively in their projects.
Ansys Mechanical enables you to solve complex structural engineering problems and make better, faster design decisions. With the finite element analysis (FEA) solvers available in the suite, you can customize and automate solutions for your structural mechanics problems and parameterize them to analyze multiple design scenarios. Ansys Mechanical is a dynamic tool that has a complete range of analysis tools.
In this session, we explored setting up Playwright, an end-to-end testing tool for simulating browser interactions and running TestBox tests. Participants learned to configure Playwright for applications, simulate user interactions to stress-test forms, and handle scenarios like taking screenshots, recording sessions, capturing Chrome dev tools traces, testing login failures, and managing broken JavaScript. The session also covered using Playwright with non-ColdBox sites, providing practical insights into enhancing testing capabilities.
Are you wondering how to migrate to the Cloud? At the ITB session, we addressed the challenge of managing multiple ColdFusion licenses and AWS EC2 instances. Discover how you can consolidate with just one EC2 instance capable of running over 50 apps using CommandBox ColdFusion. This solution supports both ColdFusion flavors and includes cb-websites, a GoLang binary for managing CommandBox websites.
This is why a security assessment is valuable for your organization.
It is important for organizations to continue investing in a well-secured Microsoft environment.
The better the security, the better data is protected and the smaller the chance of data leaks and cyber-attacks.
In addition, it contributes to maintaining a good reputation and leads to a more efficient working environment.
A SECA is an excellent way for companies to gain more insight into the security of their Microsoft environment.
What is a SECA?
A SECA, or security assessment, is an evaluation of the security of your Microsoft environment. During a security assessment, a SECA expert examines your current digital environment to detect possible risks. The purpose of a SECA is to improve the security of your IT infrastructure and reduce the chance of cyber-attacks and other problems.
What are the benefits of a security assessment for organizations?
A security assessment is very valuable if you want to optimally secure your Microsoft environment, to minimize the risk of annoying security leaks and problems. But that's not the only plus. A SECA offers many advantages for commercial and also government organizations, making it certainly worth considering.
A security assessment from Q-Advise.
Are you looking for a SECA expert? Then the experts at Q-Advise would be happy to discuss a collaboration. Thanks to our extensive experience and expertise and partner channel, we can help you get started. We are happy to help you make your Microsoft environment as secure as possible.
You can send the team an email…info@q-advise.com
Thinking about freelancing? It's not just about coding solo and avoiding coworkers. Join me as I share insights from my 15-year freelance journey, covering everything from managing invoices to client communication styles. This session blends ColdFusion-specific tips with general freelance and consulting advice, with time for audience Q&A.
Explore the latest in ColdBox Debugger v4.2.0, featuring the Hyper Collector for HTTP/S request tracking, Lucee SQL Collector for query profiling, and Heap Dump Support for memory leak debugging. Enhancements like the revamped Request Dock and improved SQL/JSON formatting streamline debugging for optimal ColdBox application performance and stability. Ideal for developers familiar with ColdBox, this session focuses on leveraging advanced debugging tools to enhance development efficiency.
Lots of bloggers are using Google AdSense now. It’s getting really popular. With AdSense, bloggers can make money by showing ads on their websites. Read this important article written by the experienced designers of the best website designing company in Delhi –
Enhancing Customer Experience in Cargo Services Through Cargo Strategy Consul...RTS corp
In the highly competitive world of cargo services, enhancing customer experience is crucial for retaining clients and fostering long-term relationships. As industries evolve and customer expectations rise, companies must adopt innovative strategies to stay ahead. Revenue Technology Services (RTS) offers specialized cargo strategy consulting to help businesses navigate these challenges and elevate their customer service standards.
Discover BoxLang, the innovative JVM programming language developed by Ortus Solutions. Designed to harness the power of the Java Virtual Machine, BoxLang offers a modern approach to application development with robust performance and scalability. Join us as we explore the capabilities of BoxLang, its syntax, and how it enhances productivity in software development.
Sami provided a beginner-friendly introduction to Amazon Web Services (AWS), covering essential terms, products, and services for cloud deployment. Participants explored AWS' latest Gen AI offerings, making it accessible for those starting their cloud journey or integrating AI into coding practices.
Join me for an insightful journey into task scheduling within the ColdBox framework. In this session, we explored how to effortlessly create and manage scheduled tasks directly in your code, enhancing control and efficiency in applications and modules. Attendees experienced a user-friendly dashboard for seamless task management and monitoring. Whether you're experienced with ColdBox or new to it, this session provided practical knowledge and tips to streamline your development workflow.
LIVE DEMO: CCX for CSPs, a drop-in DBaaS solutionSeveralnines
This webinar aims to equip Cloud Service Providers (CSPs) with the knowledge and tools to differentiate themselves from hyperscalers by offering a Database-as-a-Service (DBaaS) solution. The session will introduce and demonstrate CCX, a drop-in, premium DBaaS designed for rapid adoption.
Learn more about CCX for CSPs here: https://bit.ly/3VabiDr
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
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
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
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
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
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.