Healthy Code February - 2015 1 Healthy Code 2 February - 2015 Healthy Code February 2015 Contents 22
Total Page:16
File Type:pdf, Size:1020Kb
Healthy Code February - 2015 1 Healthy Code 2 February - 2015 Healthy Code February 2015 Contents 22 GrailsConf 4 2015 Microservices What are they and 26 why should you care? Interview with Linda Rising 12 34 Code Jugalbandi Effective Java with Groovy 16 38 Working with Let’s go with GO Spring Data Neo4J (SDN) Healthy Code February - 2015 1 Healthy Code 2 February - 2015 From the Editor Hello readers!!! It’s hard to believe, we are already into the second month of 2015. We are back with another very interesting set of articles this month. The languages. February issue is filled with loads of information about programming Rocky Jaiswal introduces us to the Go language throwing light on its about writing better Java code using Groovy. The Code Jugalbandi team is capabilities and potential. We have our Naresha continuing to impress us back with another melody and implementing it in a variety of languages. Linda Rising a renowned speaker and author talks to us about the Agile Mindset. Linda, being such a fascinating person, the interview is sure to have an impact on you forever. Microservices Architecture. This article talks Rajesh Muppalla has written a fantastic article on one of the most happening architectures, the about several issues with practical examples that will make you rethink the strategy of your projects. Arun is back with Ravikant and his favorite Neo4j. They talk about using Neo4j with Spring framework. EnjoyAnd yes! reading Do not and forget coding. to try out the quiz on Java 8. Prabhu Healthy Code February - 2015 3 Article|-------------|Rajesh Muppalla Microservices What are they and why should you care? Healthy Code 4 February - 2015 ver the last year, Microservices has emerged as a “new” approach to building large scale distributed systems. This is an introductory article Othat provides background on Microservices, their evolution, the pros and cons and the state of the art, as it exists today. You’ve recently joined a brand new client project as a lead repository. For the same reason, it was easy for the two new developer/architect. You’re sitting in a meeting room and developers to ramp-up and setup the entire application on after having heard the client’s requirements, you are now their laptop, build it and run it locally within a couple of contemplating the right architecture and technology stack hours. The release was also painless given that there was a for the project. single deployment pipeline that would take the build from the CI (Continuous Integration) server and deploy it on a Your client wants you to build an e-commerce application couple of load-balanced production boxes. for consumers. They want to support multiple clients including browsers on the desktop and mobile as well as Fast forward two years later. After the success of the MVP native mobile applications. In those cases, your system and a few minor pivots later, the customer base of the receives an HTTP request in either JSON or XML, which product has grown. Your client also boosted their sales team executes business logic, accesses database and sends back in the last two years to aid the growth. And your team has response in JSON or XML. At the same time, the system grown to 20 developers. However, the product is not able should also expose an API to integrate with third party to scale and evolve with the customer base. You realize that applications. the application feels like a big ship that’s very hard to steer. The application has grown to thousands of lines of code. This sounds like a typical layered architecture, you say to The ramp up of new developers is taking weeks instead of yourself. You have built a couple of such systems in the days. And you are finding it hard to look for developers past, so you decide to use the tried and tested architecture who can work on your “legacy” codebase. As a result of all you are comfortable with. The different layers of your these factors, you are not able to deliver as fast as you did architecture are divided into Presentation, Business and earlier to keep up with the business requirements. Database components. For the technology stack, you have a choice between Rails, Java, Scala, Nodejs, .NET etc. It really Let’s try to understand what’s wrong with the application does not matter what you use as this architecture pattern you built that’s challenging. First, give it a name. The is language or platform agnostic. However, your client term that is used for an application like the one above is: wants you to release an MVP (Minimum Viable Product) of “Monolith.” the product in the next six months. In the end, you choose a technology stack that majority of your team of four Below are some of the challenges associated with a large developers are comfortable with. monolithic application. Fast forward six months. You are at a team party to celebrate • Scaling issues - On the one hand, a monolithic application the success of the MVP which was delivered on time. can be scaled horizontally by running multiple copies The team celebrates the success but also reflects on what behind a load balancer. But on the other hand, each a small team of six (you added two developers mid-way component has its own scaling requirements as some during the MVP) have accomplished in a short time. The components are heavy on I/O and some on memory team is thankful to you for choosing the technology stack and hence have different resourcing requirements. that they were comfortable with. The layered architecture With a monolithic application, you have no choice but also provided multiple benefits. It was very easy to make to provide the same (higher) resources to the entire a change as all the code was in a single-source code application, potentially increasing infrastructure costs. Healthy Code February - 2015 5 • Technology changes and evolution - Certain problems a disadvantage for a monolith, it’s an advantage for a are best solved in certain technologies. The technology Microservice. It should also follow the Single Responsibility choices you made when you built the monolith may or Principle (SRP) and should strive towards loose coupling may not be the perfect fit when your application evolves and high cohesion that are hallmarks of well-designed at a later stage. You might want to move to a different components. technology stack or replace individual pieces of the architecture. It could be for scaling needs or for better Own build and deployment - A Microservice should be developer productivity. For eg: JVM vs C++, SQL vs standalone and should be able to run independently from NoSQL. With a monolithic application you are married other systems and services. to a technology stack for a long time. Integrates via well-known interfaces - If the Microservices • Multiple teams - Your teams are organized as UI, expose and talk using well-known interfaces using Services and Database layers. Doing any cross cutting open protocols and standards, it provides technology features takes time and also needs approval for the heterogeneity, thereby allowing teams to use the technology right prioritization. Ideally, you want to organize stack that they are comfortable with or the best suited for teams around business capabilities to reduce the the problem at hand. communication barriers so that an individual team can What’s with the name “Microservices”? take things end-to-end without a lot of overhead. And if the teams are across locations or time zones it adds I heard the term “Microservices” the first time when Fred another level of complexity. George spoke about them in his talk YOW 2012 - Brazil. Ronald Kuhn, the tech lead on Akka, thinks that the term • Continuous Delivery - Continuous Delivery is about Microservices is too ambiguous and likes to call them reducing the time it takes for a commitment made Uniservices instead, given on what they do. by a developer to hit production. It is hard to follow continuous delivery practices when you have a single Netflix used to call its implementation of Microservices as large codebase. The cycle time will be larger because the cloud native architecture and fine grained Service Oriented entire application has to be built, tested and deployed Architecture (SOA) but they have started to use the term for any change. In addition, each of the deployments is Microservices since that has become widely accepted. a high risk deployment. How is this different from Service Oriented • Ramp-up of new members - A large monolithic project Architecture (SOA)? is intimidating for new developers as it can take a long time to setup, build and run locally. At the heart of it, both Microservices and SOA try to combat the challenges associated with large monolithic Is there a solution? applications. SOA’s approach uses protocols like SOAP, RPC, a complex middleware called ESB that meant different Yes. Microservices. A small autonomous set of services that things to different people. work together, that can be scaled and released independently with different teams potentially using different languages It had sound principles but there was a lack of consensus across different locations. on how to do SOA. Moreover, the implementation itself was monolithic where dumb services were integrated with So, how do we describe a Microservice? a smart ESB. Proponents of Microservices look at it as a Autonomous - Each service can be built using the specific approach to SOA in the same way that XP or Scrum appropriate tool for the job. Multiple teams of developers are different approaches for Agile software development.