Develop Reference

Where envoy Istio fits in to microservice application

I am trying to understand full picture of microservice architecture. I work on java so worked with spring boot applications.
As per my understanding spring has good integration with Netflix modules like service discovery , zuul api Gateway, hystrix and other modules. But when it comes to production applications which are deployed as containers in any cloud providers with kubernetes as orchestrated I can see they use envoy and Istio for resilience load balance and other tasks.
I don’t understand where Istio and envoy fits here instead of Netflix oss modules

Istio fits to microservices because it enables you to abstract similar implementations (Retries, Circuit Breaking, Logging, Tracing, etc..) done differently by different frameworks and languages into sidecar containers.
One core principle of microservice architecture is that "We should enable our teams to pick the technology stack (Language, Framework, CIs, etc..) that they think fit the use case of each component". However, we would want to ensure that every single one adheres to cross cutting concerns like retries, circuit breaking, logging, tracing which is a rule that spans across entire ecosystems.
Diversity across tools sometime introduce different behaviors (eg. Go and C# libraries for retry might have libraries that differentiate in terms of little details that matter to you) and this is what Istio is exactly trying to solve.
It allows you to write re-usable sidecar containers that complement existing behavior of your existing apps so that they don't have to worry about cross cutting concerns because they are already integrated with your layer 5 (Service Mesh)
PS: Welcome to Stackoverflow!

Microservice architecture, what is a service in this case

I'm reading some documentation about the micro-services architecture (through this link for example) and I was wondering what is exactly a service in this case.
In IT, everything could be called a service:
- a SPRING REST application launched through the java command like:
java -jar build/libs/gs-rest-service-0.1.0.jar
It could also be a classes corresponding to the business layer in a DDD
It could be simply something related to the domain studied, like providing something to somebody
and many others... (android background running services etc...)
But in microservices, what does it mean? And what kind of technologies / tools are used to create a "service running by himself" in the Java EE stack for example? It's only related to webservices?

Exactly, that's the beauty of microservices model! You can start thinking about microservices when you design your maven multi-module project, for example. Low coupling, clear separation of concerns, may be even asynchronous communication. When you feel more confident you extract them in into apps and run in a one host, next step - run in different hosts. It's up to you to decide how exactly they should be deployed, it's related to goals you want to achieve (fault-tolerance vs low latency, etc.) and DevOps resources you have (because more separation you have more maintenance you need).
Regarding Java EE stack - nothing specific, just usual jar or war file running using java -jar or application servers like Tomcat.
Another direction is to use tools like Docker + CoreOs / kubernetes / ..., Mesos + Marathon, etc., but they are suitable for any languages / frameworks in microservices.
Edit:
Microservices can use a combination of synchronous (REST, SOAP) and asynchronous protocols (messaging queues like ActiveMQ, RabbitMQ, etc). It's up to you to decide how to combine them. My example: labs.bench.co/2014/12/10/microservices-at-bench-intro

Previous answers are great.
Microservices architecture is just a functional decomposition design.
I suggest you to read this blog post : Microservice Design Patterns
From a technical point of view, there is a a lot of tools like Docker (to run each microservice as a linux container) and Kubernetes to orchestrate them as a service (here is a Kubernetes sample).

My own definition:
A microservice is a stand-alone, decoupled component that handles a single business concern, and is consumable from other services.
Others might agree or disagree, and there is a lot of interesting discussion on this topic that make it a great study point for software engineers.
From a technical standpoint:
You can create microservices in almost any technology: Java EE, Java + Spring, Python, Rails, Grails, Node.js and so forth. From what I have seen, it seems most commonly applied in the domain of web apps and back-end service-oriented ecosystems. In the article you reference, the NetFlix model is a very interesting thing to study, because you can see all the elements of a microservice architecture in depth: service discovery, circuit-breaking, monitoring, dynamic configuration, and so on.
Some things you might want to check out, if you are Java-oriented:
Spring Cloud allows you to use some of these same NetFlix components with a minimum of hand-coding: http://cloud.spring.io/spring-cloud-netflix/
An actual operational example on github (not mine, but I have used it in my own learning on the topic): https://github.com/ewolff/microservice
From a conceptual point of view, your question hints at a notorious microservice design dilemma. There is not necessarily a "correct" level of granularity for a microservice. The idea is to choose a level of granularity that has meaning within your business domain. If you implement microservices at a very low level of granularity, (e.g. the CRUD level), then you will almost certainly end up with very chatty services and you will probably have to build more meaningful composite services over top. If you choose too high a level of granularity, you could end up with a more monolithic application which may require refactoring into microservice-sized pieces later.

I would start with Your last question - It's only related to webservices?
That's debatable. I would say, NO. It's related to webservice (but not only to it.)
Martin fowler describes microservices as a small subset of SOA, after all microservices are services, and SOA is a very generic and broad term.
Below are some of the important aspects of Microservices:
Each service (or a set of few) should have it's own data store.
Services are organized around the business needs or functionality.
Each service is independent so they can be implemented in any language. Leads to polyglot programming culture in team.
Service can take request from client or from other services as well.
They are usually event driven and asynchronous so scaling becomes easier.
Services are dumb as they only do one thing (but they should be self sufficient to monitor themselves)
They can be helpful in continuous deployment or delivery as implement to deploy cycle is really small.
They are very small so there is not much of network overhead in deploying them. So they can be deployed across a cluster of nodes in few minutes.
Also, I want to stress that, above are NOT only true about microservices. Companies like google, netflix, and Amazon have been doing similar thing even before the term was coined.

Service to microservice is Java is to JavaScript. Don't think about it that way. Instead microservice can be thought of as the following:
A small problem domain.
Built and deployed by itself.
Runs in its own process.
Integrates via well-known interfaces.
Owns its own data storage.

A Microservice is basically a self contained process that provides a unique and single business capability. We don't create web Microservice, business logic Microservice, or datebase Microservice.
Why Microservice?
Microservice make our system loosely coupled, i.e. if we need to update, repair, or replace a Microservice, we don't need to rebuild our entire application, just swap out the part that needs it.
To built each Microservice can use different languages and tools. Microservices communicate with well defined interface
The communication should be stateless for scalability(copies of Microservice) and reliability(one copy fail other copy can serve), the most common methods for communication between Microservices are HTTP and messaging.
Each Microservice should have it's own datastore.
Small team capable to work on design, web development, coding, database admin and operations.
source

Microservices is a software architectural style that require functional decomposition of an application.
Usually, it involves a monolithic application is broken down into multiple smaller services, each deployed in its own archive, and then composed as a single application using standard lightweight communication, such as REST over HTTP or some async communication (of course, at some point micro services are written from scratch).
The term “micro” in microservices is no indication of the line of code in the service, it only indicates the scope is limited to a single functionality.
Each service is fully autonomous and full-stack. Thus changing a service implementation has no impact to other services as they communicate using well-defined interfaces. There are several advantages of such an application, but its not a free lunch and requires a significant effort in NoOps.
It's important to focus on that that each service must have the properties of:
Single purpose — each service should focus on one single purpose and do it well.
Loose coupling — services know little about each other. A change to one service should not require changing the others. Communication between services should happen only through public service interfaces.
High cohesion — each service encapsulates all related behaviors and data together. If we need to build a new feature, all the changes should be localized to just one single service.

Upgrading large application from spring 3.0.x to 4.1.x - What best practices / procedures should I follow?

I've been using Spring for about a year, and I'm comfortable enough using it, but I've avoided jumping under the hood for the most part.
I'm tasked with upgrading a large, mission critical enterprise application, from Spring 3.0.x to Spring 4.1.x.
What are the best practices for making a large, inevitably finicky and complex change like this? (Anything above and beyond 'throw in the jar files and see what happens' and 'read the documentation here: http://spring.io/' would be very helpful)
The system:
Java 6 - jax-b/-p/-ws/, Apache Commons,
Spring 3.0.5 - the usuals (core, context, beans etc), MVC, AOP, ORM, JDBC, Acegi
Hibernate 3.5
Tomcat 6
0 unit tests or automated testing of any kind.
Maven dependency management and build automation.
Half controllers using annotations for request response mapping, half using simpleFormController pattern, half autowired, half hooked up with xml.
Hundreds of views, scores of controllers.
Steps I've taken so far:
Prepared a (mostly automated) regression testing script (so that I can ensure I haven't broken anything)
I've started reading through the 'upgrade guides' one at a time, "upgrading to 3.1", "upgrading to 3.2" and making notes on things that sound familiar, but I think I'd need to have a much deeper grasp of our system, and spring in general, before I could be confident of this as an exhaustive approach. This just generally feels like a haphazard approach, which is not what I want for such a complex change.
My questions:
What steps/procedures are considered 'best practice' in these for a job like this?
Does anything jump out at you as a 'gotcha' for a job like this?

Obviously, there won't be "standard" set of recommended practices because every migration/upgrade is different. Here're my thoughts:
Requirements, requirements, requirements
Regression testing script is great start. If there is a complete documentation of the features/functionality, then your "success criteria" for migration is straightforward.
If the documentation is incomplete/non-existent, then double and triple check to make sure that all 'requirements' are captured with your tests. Might be a good idea to create documentation too. And have the product manager/supervisor sign off on it. You'll be surprised at how many 'hidden' requirements exist even in simple systems. There is a big risk of underestimating the effort needed for migration without comprehensive requirement.
It is extremely critical to set the right expectations in terms of timelines. Perhaps an agile approach with biweekly demos of how much progress you've made will help keep everyone on the same page.
Spring projects have evolved a lot. Budget for learning time.
This could be a big gotcha. Spring projects and Java development have evolved a lot since Spring 3.x. Big changes include:
Java 8 features
JavaConfig (as opposed to xml configuration)
Acegi is now Spring Security
Spring projects typically use Spring Boot
Switch from Maven to Gradle for building projects
Full CI using Jenkins (or other CI tools)
Unit and integration testing have moved on to using annotations (and mock frameworks)

Well, it is not easy to answer you question since there are many things to be taken into account.
First of all I can suggest you to use the Migrating from earlier versions of the Spring Framework guide that's coming directly from the 'source'.
I would especially draw you attention to the 'Enforced minimum dependency versions' section that recommends you the minimum version level of some wide used libraries.
Obviously in the moment you insert these new versions they're bringing with them some transitive dependencies that might generate conflicts.
Take also a look to the dependency updates section.
Also remember to correctly define the scope of the dependencies in your pom files, since many of them could be provided by the infrastructure you're using (i.e. Tomcat).
I think you will be required to move to Java 7 or 8 and also Tomcat should be updated to version 7 or better 8.
Moreover try to automate as much as you can your building and testing environment with maven along with adopting a CI environment like Jenkins (or Hudson if you prefer the product).
It is also very important to perform unit testing of every single little method/piece of code, since it will make integration tests easier.
You should also become familiar with Spring 4.x new features and try to exploit them especially those regarding testing improvements.
A little resume of new features is the following:
Removed Deprecated Packages and Methods
Java 8 Support
Java EE 6 and 7 become the baseline
Groovy Bean Definition DSL
Core Container Improvements
General Web Improvements
WebSocket, SockJS, and STOMP Messaging
Testing Improvements with extreme use of annotations
Take also a look to Spring MVC Test Tutorial by Petri Kainulainen that can give you a lot of informations about testing.

You have to have answer to the following before you proceed.
Is the need to upgrade is only the libraries and runtime for some sort of dependencies ?
OR
You really want to get the most out of Spring 4.x ?
Once you decide this you can take proper course. Those regression scripts you have created will help in both the scenarios. If you can think of some crude throwaway utility that will hit every public api with some valid input and capture the output and be able t compare this in the both worlds that may help but it may not be applicable in your situation.
So if you want to get the benefit of the Spring 4.x I would suggest you focus on productivity aspects and create an inventory of these things.
You may redesign the whole app in Spring 4 as if it is a new application.
Once you can envision the future state. The next problem reduces to going from Point A to Point B i.e. a matter of best migration path.

From Migrating from Spring 3 to Spring 4, you would probably get some help from the Spring project's
Spring Integration 3.0 to 4.0 Migration Guide on Github.
Hope it helped!

Can't we use spring for distributed java applications?

This came as an interview question.
The interviewer asked me if you can use spring for all the purposes and get away without using any of the Java EE framework .
I said yes, but he asked me how about if the application is distributed and what is the point of application servers.
I am not sure about the answer.
Does Spring do everything that the Java EE framework does?

Well, Spring is wide. So you can review point by point. I'm not specialist in Java EE but I'm sure Spring can cover a lot (if not all) of Java EE concerns. And I'm pretty sure Spring can handle most of layers/concerns in an application.
First of all, Spring IOC. You can configure an object graph with Spring IOC. It helps at any layer configuring all the components you need to implement a layer.
Spring-MVC-Web: you can configure an MVC web component in order to handle and serve all web application requests. I think you can make something cool with it. Configure web responses and its necesary configuration with other business elements (including IPC - Inter Process Comunication).
Spring Security is heritage from Acegi. It's a web framework for defining role-defined access to web resources.
I'm not sure if Hessian is Spring's too. Anyway it's lightweight and it helps comunicating with components in other processes à la RMI.
Well... I'm not sure about persistence, but I thing Spring has templates for JDBC, Hibernate, and all, so it can help anyway (as suggestions indicate: JmsTemplate and RestTemplate are available for communication with other business components!).
The core thinking here is: you can make an app from scratch, so in all cases, Spring can provide a framework to ease the difficult/repetitive tasks on every layer. Does Spring does it? Yes.
Please check other features to see if Spring has something for it. I'd bet it.

Deep down, Java EE is a set of specifications (some of which have been contributed by Spring team!)
Spring's mission statement is to 'Simplify Java Development'
It does so using the following techniques:
POJO -> facilitates easy testing
DI -> promotes loose coupling
AOP -> promotes separation of concerns, maintainability etc
Templates -> provides a standard programming model which does the heavy lifting for you
Spring and Java EE do not have a "Vs" relationship.
Using the above techniques, the Spring Framework lets you build (Java EE) standards-based applications more efficiently.
>Does spring do everything that the Java EE framework does ?
Based on what I've said above, the question might be rephrased as 'Does Spring have support/implementations for all the technologies that comprise the Java EE specification?' -
Nope, but it does do what it set out to do and that is simplify development on most Java EE technologies.
That said, the trade-off for this simplification of Java development is that you need to now have significant amount of knowledge (of the Spring Framework) at your fingertips... (comes with practice and google :) )
>Can't we use Spring for distributed java applications?
Sure you can. Spring has a whole lot of Exporters/FactoryBeans and Clients(Templates) for most conceivable use cases.

Yes Spring can be used in a distributed application without Java EE. We have used it to send messages to MQ and update a database both within one XA transactions.
According to this article, Spring can definitely be used on its own in a distributed application.
http://www.wrox.com/WileyCDA/Section/Why-Use-the-Spring-Framework-.id-130098.html
http://www.artima.com/forums/flat.jsp?forum=276&thread=204508

Historically, (5 years ago?) Spring was weak in the distributed applications area, in particular database clustering. That is no longer a concern. I would say that Spring is going even further for distributed computing these days as they are vigorously pursuing cloud technologies which Java EE hasn't approached yet.

In my view the main benefit of Spring was that it did away with some of the more heavyweight components of the Java EE framework (Entity Beans, session beans) and replacing them with a lightweight alternative.
On of the main benefits of Spring as I see it, is that it decouples a lot of components and then uses XML or Annotations of wiring them together. That makes it easy to write Unit Tests (by injecting mock components instead of real ones), which wasn't something easily done when using heavyweight Java EE components (couldn't easily unit test EJB 2.1 Entity Beans).
A lot of Spring concepts have since gone into the Java EE standards, so I would argue that Java EE is no longer a heavyweight option, and Spring works will with Java EE components such as application server managed connection pools (via JNDI), transaction managers, queue managers that can very easily be managed using an application server which can provide additional functionality such as clustering, failover, load-balancing, serving web resources...
Having said that, the people behind Spring (VMWare) have their own application server (tcServer) which is based on Apache Tomcat and provides a lot of the glue used by spring, but is not considered as "heavy" as some of the traditional Application servers (Websphere, Weblogic).

I don't think so. Basically Spring is about integration between Java EE frameworks.

Use spring inegration framwork for this .
Use can uss Akka framwork for managing distributed applications with spring integration .
Akka uses the Actor Model together with Software Transactional Memory to raise the abstraction level and provide a better platform to build correct concurrent and scalable applications.
Take a look at the step by step tutorial that gives more information about how to build a distributed application using Akka framework.
In general, distributed applications are built in Java using Java-RMI that internally uses Java's inbuilt serialization to pass the objects between the nodes.

When to use Spring Integration vs. Camel?

As a seasoned Spring user I was assuming that Spring Integration would make the most sense in a recent project requiring some (JMS) messaging capabilities (more details). After some days working with Spring Integration it still feels like a lot of configuration overhead given the amount of channels you have to configure to bring some request-response (listening on different JMS queues) communications in place.
Therefore I was looking for some background information how Camel is different from Spring Integration, but it seems like information out there are pretty spare, I found:
http://java.dzone.com/articles/spring-integration-and-apache (Very neutral comparison between implementing a real-world integration scenario in Spring Integration vs. Camel, from December 2009)
http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html (Comparing Camel with other solutions, October 2009)
http://raibledesigns.com/rd/entry/taking_apache_camel_for_a (Matt Raible, October 2008)
Question is: what experiences did you make on using the one stack over the other? In which scenarios would you recommend Camel were Spring Integration lacks support? Where do you see pros and cons of each? Any advise from real-world projects are highly appreciated.

We choose Camel over Spring-Integration because the fluent API is really nice. We actually use it in Spring projects and use Spring to configure part of it. The programming API's are clear and there is a large set of sensible components.
We did a small scale shootout and basically at that time for our requirement Camel won. We use it mainly to transfer internal datafiles to/from external parties which usually requires format conversions sending it using ftp/sftp/... or attaching it to an email and sending it out.
We found the edit-compile-debug cycle reduced. Using groovy to experiment setting up routes are added bonuses.
Spring-Integration is a great product too, and I am quite sure it would satisfy our needs too.

I only recommend Spring Integration if you already have got a Spring project and you have just to add some "basic" integration using File, FTP, JMS, JDBC, and so on.
Apache Camel has two main advantages:
Many, many more technologies are supported.
Besides, a (good) XML DSL, there are fluent APIs for Java, Groovy and Scala.
Because Apache Camel has very good integration with Spring, I would even use it instead of Spring Integration in most Spring projects.
If you need more details, you can read my experiences in my blog post: Spoilt for Choice: Which Integration Framework to use – Spring Integration, Mule ESB or Apache Camel?

I have recently conducted a Camel vs Spring Integration shoot-out with the aim to integrate Apache Kafka. Despite being an avid Spring developer, I sadly found my suspicion with Spring's ever-growing Project stack confirmed: Spring is awesome as IOC-Container to serve as glue for other framework, but it fails at providing viable alternatives to those frameworks. There might be exceptions to this, namely everything to do with MVC, where Spring came from and where it does a great job, but other attempts to provide new functionality on top of container features fall short for three reasons and the SI Kafka use case confirms all of them:
Introduction of a long-winded difficult to use DSL for XML-configuration.
Pages of xml-configuration code to get all framework components wired-up.
Missing resources to provide functionality on par with dedicated frameworks.
Now, back to the results of my shoot-out: most importantly I am impressed by Camels overall concept of routes between endpoints. Kafka seamlessly integrates with this concept and three lines of configuration are enough to get everything up-and-running. Problems encountered during the process are neatly addressed by ample documentation from the project team as well as a lot of questions on Stackoverflow. Last but not least, there is a comprehensive integration into Spring that leaves no wishes unfulfilled.
With SI on the contrary, the documentation for the Kafka integration is quite intense and still fails to explain clearly how to integrate Kafka. The integration of Kafka is pressed into the SI-way of doing things, which adds extra complexity. Other documentation, e.g. on Stackoverflow is also less plentiful and less helpful than for Camel.
My conclusion: cobbler stick to your trade - use Spring as a container and Camel as system integration framework.

It really depends on what you want to do. If you need to extend something to build your own messaging solution Spring Integration has the better programming model. If you need something that supports many protocols without custom code, Camel is ahead of Spring Integration.
Having a small scale shootout is a very good idea, just make sure you're trying to do the type of things that you'd typically be doing in the project.
--disclaimer: I'm a Spring Integration committer

Most comparisons of Camel and SI that I've seen don't take the following into account:
1.) The effect that Spring Boot has had on developer productivity for Spring Integration
2.) The effect of Spring XD has had on making Spring Integration applications available with no code compilation - also Spring XD sources and sinks are simply Spring Integration channel adapters, when you're looking to extend Spring XD.
3.) The effect of Spring XD has had on making unifying Spring Integration, Spring Batch, Spring Data (+Hadoop!) in one stack, effectively bringing batch and stream processing, HDFS/Apache Hadoop support, and much more to Spring Integration.
4.) The effect of the soon-to-be-released Spring Integration 4.0 Java DSL https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference
For your consideration,
/Pieter (disclaimer I work at Pivotal)

We are using Spring Integration for our application and now considering to move to Apache Camel as we encountered lots of issues with Spring Integration framework. Here are couple of issues.
The CachingConnectionFactory which Spring provides opens 1000's of idle connections in IBM MQ and there is no guarantee that these connections are reused. And still these connections will stay open forever which creates troubles on the MQ side. Had to restart the application every week in lower environments just to refresh the connections. Apache Camel also provides Caching and the connections seems to go up/down based on the load.
Spring doesn't provide mappers for QoS parameters. Even if you enable QoS, the delivery mode and expiration/timetolive properties will get lost (I am going to raise a JIRA issue for this). Apache Camel handles this and QoS parameters are sent to upstream applications and not dropping it.
I am right now working on issues with handling the exceptions and transactions with Apache Camel which Spring seemed to handle better with AOP.

Apache Camel is a very good framework and very complete too. But if your application uses spring, my personal advice is to use Spring Integration.
Spring Integration is the integration EIP complaint framework of Spring-Source ecosystem. It has excellent integration with the ecosystem: Spring boot, Batch, XD; even the core uses same abstraction starting from Spring Framework 4. Some of the messaging abstraction were moved in the framework, as proof that the basic messaging abstraction of Spring Integration is very strong. Now Spring framework for instance use the messaging abstraction for Spring Web, web socket support.
Another good thing in a Spring application with Spring integration respect to use Apache Camel is that with Spring integration, you can use only one Application Context. Remember that the Camel Context is a Spring context. if you have the chance of use a new Spring version, I suggest to use Spring Integration Java DSL for configuration. I use it on my new projects, and it feels more readable and clear. I hope that this reflection can help you for the your evaluations.

Actually, I would say FTP has graduated its incubation period. You can do a simple search on SI forums/JIRA to see what new features were implemented and bugs that were fixed. From various chatter it seems like there is already some production usage out of it, so I would suggest to give it a second look and of course communicate your concerns to us via
http://forum.springsource.org/forumdisplay.php?42-Integration
https://jira.springsource.org/browse/INT
Cheers
Oleg
Disclaimer: I am Spring Integration committer

One reason to use Camel over Spring Integration is when you need a more featureful EIP set. Spring Integration doesn't provide abstractions over things such as ThreadPool.
Camel does provide additional constructs for this simplifying some of the aspects of working with concurrent code:
http://camel.apache.org/camel-23-threadpool-configuration.html
If you have no need for this sort of thing and just want to connect file, JMS, FTP endpoints etc... then just use Spring Integration.

Camel act as middleware for application where one can perform data modeling, transformation of message values and choreography of messages.

If your current application is in Spring and require features which are supported by Spring Integration of EIP then Spring Integration is the best option else require more third party supports/protocols/file formats etc