EAAS

by

What Is Spring Boot and Why Should It Be Chosen Over Spring?


Do you wish to speed up your web development? Are your projects unable to meet the deadlines set by the clients? Do you want to fast track your applications?

Why was Spring Boot Needed?

Before understanding Spring Boot, you will have to understand why it is needed? For Java developers who choose Spring over the older and more complex Java EE, Spring provides speed and scalability along with various components in its ecosystem that eliminate redundancy from coding.

Spring introduced concepts like dependency injection, REST, Batch, AOP, and others, etc. Spring was also easily integrated with other frameworks like Struts and Hibernate. However, there were still qualms related to the configuration complexities of the Spring projects. Since Spring is mainly used for the development of enterprise and large-scale projects, these projects require external Java files and need to be configured heavily.

For developers who work on small projects, the difference in the configuration of enterprise projects is noticeable. As a developer, it is undesirable to spend a lot of time on the configuration when that time can be utilized in the coding of business logic.

Hence, with the arrival of Spring Boot, developers have received a much-need boost that eases up their development complexities. The important thing to note with Spring Boot is that it is not a web framework and, therefore,  cannot be viewed as a complete replacement for Spring framework. Rather, it is a solution or an approach for web development in Java that minimizes the heavier configurations and dependencies. This means that as soon as you start a Spring Boot project, you can run it instantly without many configurations. Because of this, it has become one of the most popular tools in the development of Spring projects.

What is Spring Boot?

With the emergence of Spring Boot, Java developers are able to center their attention on the application logic. This means developers are saved from the complexities and difficulties associated with the configuration of web projects. The important thing to note with Spring Boot is that it is not a web framework. Rather, it a solution or an approach for web development in Java.

Why Spring Boot Over Spring?

The questions that come into mind with the mention of Spring Boot are, “Why should I use it when there is Spring? Is it an extension of Spring?”

Starters

Are you tired of searching Google for the source codes of different dependency descriptors? Spring Boot has a certain feature called ‘starter’. These starters are available for a number of use cases, which is handy for quick configurations. With a starter dependency for the most used Java technologies, these starters are highly productive for the POM management and help in the development of production-ready applications. Some of these are the following.

Web

Suppose you are building a REST service. You may need to use Spring MVC, Jetty, and Jersey for your web project. All of these technologies require their own set of dependencies. So will you add all of them?

Fortunately, with the Spring Boot starter, you will only be required to type a single dependency known as ‘spring-boot-starter-web’. Now, you can proceed to write your REST service without adding any further dependency.

Test

Whether you use JUnit or Spring Test for your testing, you will have to add all of them one-by-one in your project. However, with the help of ‘spring-boot-starter-test’, all your testing dependencies can automatically be managed. If the need for the upgrade of the Boot library arises in the future, then you will just have to make a single change for the Boot version.

JPA

Persistence is a common feature of Java’s web projects. Mostly, it is Java Persistent API (JPA) that requires its own set of dependencies. However, with a single line addition of ‘spring-boot-starter-data-jpa,’ all of the required dependencies are automatically managed.

Opinionated Default Configuration

Whether you are working with Groovy or Java, Spring Boot provides convenience with the help of the coding conventions of the opinionated default configuration. This means that developers do not have to spend time in the writing of boilerplate code. Likewise, the XML annotations and configuration complexities can also be reduced significantly. As a result, the productivity of a project increases considerably.

Integration

Spring’s projects need to be configured so a developer can get its ecosystem’s necessary features. The use of Spring Boot does not mean leaving the Spring’s ecosystem. In fact, Spring Boot helps with the integration of Spring technologies like Spring JDBC, Spring Security, and others to your development toolbox.

Scripting

Spring Boot comes with a command line module that can be used for Spring scripts. These scripts are written in the JVM language, Groovy. Groovy adopts various features from Java, and thus it provides convenience for Java developers to use without meddling with the boilerplate coding conundrums. The tool can also be used with Spring’s Batch, Integration, and Web.

Type-Safe Configuration

Spring Boot also comes with the support for type-safe configuration. This helps in the validation of the configurations of web projects.

Externalize Configuration

Do you consistently need to modify your configurations as you write a code in a variety of software environments? With Spring Boot, developers have the ability to externalize their configuration and write the same code for all the environments. As a result, reusability is increased in the projects.

Logging

Spring Boot also helps common logging for internal logging. This means that all the dependencies of a web project are set by default. However, developers can customize these dependencies if needed.

Embedded Servers

Spring Boot provides Embedded Servers. This means that you can eliminate the need of WAR files from your toolkit. Instead, you can now create JAR files and put your Tomcat Web Server inside the JAR file. This JAR file is called an embedded server. Now this embedded server can be run on any machine that recognizes JVM.

First Spring boot application

Before you start building spring boot application you need to have some tools ready.

  • Java 8 and above
  • Apache Maven 3.3.9
  • Spring STS/eclipse

 

  1. Open STS IDE select New-> Maven project. Select your workspace location.
  2. In New maven project explorer select “maven-archetype-quickstart”
  3. Enter Name of your application (Let say “myFirstSpringBootApplication”) and click the finish button.
  4. Open pox.xml and add spring-boot-starter-parent and the spring-boot-starter-web dependency.

<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.3.RELEASE</version>
</parent>

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>

  1. Go to App.java which was created by default and add @SpringBootApplication               import org.springframework.boot.SpringApplication;
                   import org.springframework.boot.autoconfigure.SpringBootApplication;              @SpringBootApplication
  2. Create a new class TestMyFirstSpringBootApplicationController and write the code like this.

import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class TestMyFirstSpringBootApplicationController {
      @RequestMapping(“/”)
      public String firstMethod() {
             return “yey .I wrote my first application!”;

}

}

 

  1. Start your application by clicking on Run As-> Java Application
  2. Test your application. Open the web browser and type http://localhost:8080. You should see the message “yey. I wrote my first application!”;
  3. Write your comment on my blog and suggest if you want to update /add anything

 

Final Thoughts

Are you exhausted with the management of dependencies? Do you hate to continuously write boilerplate code? Well, then you should certainly think about using Spring Boot, especially for small projects.

by

Message-Driven Architecture


A message-driven architecture can have the following components.

  • Producer – The one that generates a message and then forwards it ahead.
  • Consumer – The one for whom the message was intended; who will then read it and process accordingly.
  • Queue – A communication model that saves the messages so they can be sent ahead to other services for processing.
  • Exchange – It is a queue aggregator. This means that it can apply abstraction on the queues and manage the messages so they can be sent to the right queues.
  • Message – It consists of the headers which contain metadata as well as a body. The body entails the actual contents of the message.

A message-driven architecture also needs a message broker. This message broker decides who should send the message or who should receive it.

Surely, the benefits of the microservices outweigh those of monolithic applications but the paradigm shift means that you will have to look into the communication protocols and processes between various components of your application. By using the same mechanisms of monolithic systems in a microservices application, it may impact the performance of the system and slow it down, particularly if you are coding distributed applications.

To counter such problems, the isolation of the microservices architecture can be helpful. For this purpose, asynchronous communication can be utilized to link microservices. This can be done through the grouping of calls. The services in a microservices application are often requires interaction through protocols like HTTP, TCP etc.

The general opinion of the developers regarding the microservices architecture is to inject decoupling in applications while maintaining the cohesiveness of the system. A true microservices applications is one in which each service has its own data model and business logic.

A protocol can be either asynchronous or synchronous. In the synchronous protocol, a client can forward a request. The system will then listen for a response. The entire process is independent with client code execution. An example of such messaging is the HTTP protocol. In asynchronous protocols, the sender will not listen or wait for a response.

Types of Message Brokers

There are many message brokers that are used for message-driven architectures. Some of these are the following.

RabbitMQ

RabibtMQ is perhaps the most popular message broker out there. It is open-sourced and uses the Advanced Message Queuing Protocol (AMQP) with cross-platform functionality. Whether you are a Java developer or a C# one, all of your microservices can be used to communicate the message with different microservices.

Azure Event Hub

This one is a PaaS (Platform as a Service) related solution that is offered by Microsoft Azure. It does not need any management and can be easily consumed by a service. It also uses AMQP. It basically has an Azure Event Hub that works with partitions and communicates with consumers and receivers.

Apache Kafka

Kafka is the brainchild of Linkedin and was made open-source in 2011. It is not dissimilar to Azure’s solution and has the capability to manage millions of messages. However, the difference stems from the fact that unlike the Event Hub, it works with IaaS (Infrastructure as a Service). Though, newer solutions are also integrating Kafka with PaaS.

There are two types of asynchronous messaging communications for message-driven architectures.

Single Receiver

Single receiver message-driven communication is particularly helpful when dealing with asynchronous process while working with different microservices. A single receiver is one in which a message is sent only once by its consumer. After forwarded, it also will be processed only once. However, it must be noted that at times a consumer may send the message more than once. For example, there is an application crash; the application will try to repeat the message. In the case of an event like an Internet connectivity failure, the consumer can send a message multiple times. However, it must be noted that it should not be combined with the HTTP communication that is synchronous. Message-driven commands are especially useful when developers scale an application.

Multiple Receivers

To get your hands on a more adaptable technique, multiple receivers message-driven communication can be proficient. This communication utilizes the subscribe/publish strategy. This refers to an approach where a sender’s message can be broadcasted to multiple microservices in the application. The one who sends a message is called the publisher while the one who receives it is called the subscriber. Additionally, further subscribers can be added to the mix without any complex modification.

Asynchronous Event-Driven

In the case of asynchronous event-driven communication, a microservice will have to generate an event for integration. Afterward, another service is fed with the information. Other microservices engage in the subscription of events so messages are received in an asynchronous manner. Subsequently, the receivers will now have to upgrade their entities that entail information regarding the domains so further integrations events can be published.

However, here the publish-and-subscribe strategy requires tinkering with event bus. The event bus can be coded in such a way that it occurs as a means of the interface while dealing with API (Application Programming Interface). To be more flexible with the event bus, other options are available through processes like a messaging queue where asynchronous communication and the publish-and-subscribe strategy are fully supported.

However, it must be noted that all the message brokers have different levels of abstraction. For example, if we are talking about RabbitMQ, then it has a lower level abstraction if we compare it with solutions like MassTransit or Brighter. Brighter and others use RabbitMQ for abstraction. So, how to choose a message broker? Well, it depends on your application type as well as the scalability needs. For simple applications, a combination of RabbitMQ and Docker can prove to be enough.

Though, if you are developing large applications then Microsoft’s Azure Service Bus is a powerful option. In the case of desiring abstraction on a greater level, Brighter and MassTransit are the good options. If you are thinking about developing your own solution then it is not a good idea since it is time-consuming and the cost is too high.

by

What Is Event-Based Architecture?


Before reading about event-based architecture, you will need to understand what an event is. An event can be termed as any ‘change’ that occurs between two states. For example, a module in application sends a message to another component. This message can be the event that will trigger a change in the processing of the system. Event-based architectures are favored because they help software development of asynchronous and scalable applications.

What Is Event-Based Architecture?

Event-based architecture is a type of software architectural design in which the application component receives the notification of an event. As a result, a response is generated. In comparison to other paradigms, event-based architecture is considered loosely coupled. EDA can be considered as an approach for coding software solutions where the heart of the architecture lies in ‘events’ which process the communication between different components.

How Does Event-Driven Architecture Work?

The architecture has several components that help to speed up the development process of an application.

Queue

In an event-based architecture, the requests accumulate into queues called event queues. From these queues, the events are then sent to the services where they are processed.

The events in this architecture are collected in central event queues. For example, check the following diagram.

queue

 

 

 

S here denotes the service. The queue will provide an event for each service accordingly.

Log

The event log exists on the hard disk. It consists of the messages that were written for the event queue. An event queue is useful because in case of an unexpected system shutdown or crash, rebuilding can be eased through the contents of the event log. The following diagram will help to explain the event log’s place in the architecture.

 

log

 

 

 

The event log can also be utilized for any future back up. This back up can take the entire state of the system which can be critical in testing. The comparison between the performance of both the old and newer releases of an application can be analyzed through this backup.

Event Collector

Okay so far we have talked about the collection of the events in the event queue but how exactly are the events received? Well, the answer lies within the term ‘event collector’. These collectors get requests from protocols like HTTP and forward them to the event queue. Further understanding can be gained through the following diagram.

eventCon

 

Reply Queue

Not all the events can be categorized as same. Sometimes, an event does not require a response. For example, a user has entered some data in a feedback form. In this case, the system does not require sending a response. However, some events require the system formulating a response for a request. The request here will be called as an ‘event’ in our architecture. For this response, a reply queue is needed which will utilize the event queue. The collectors that forward the events can also provide the response back. However, it must be noted that the event log does not record the contents of the reply queues. The following diagram can explain the reply queue.

 

 

replay

 

Read vs. Write

When all the requests from the collectors act as an event to trigger a function, then all of them are added in the event queue. In the case, this queue is linked to the event log. All the requests are persisted which slows down the system. If some of the non-important requests can be eliminated then the event queue’s processing can be increased considerably.

The core concept behind this persisting of events is the rebuilding of the former states of a system. This means, events that actually modify the state of the system, need to be persisted to the event log. This can be done through the classification of events into write and read events. A write event is one in which the states of the system are modified while a read event does not modify any state. As a result, the application can now only persist during the write events which in turn will provide a much-needed boost to the management and processing of the event queue.

Ratios between both read and write events can be drawn to further gain an understanding of the difference. For instance, our system has 10 events. Out of the 10, only 2 events are actually changing the state of the system. Without classification, we can find all of them to be slowing the speed of the event queue through persistent to the log. However, by dividing them between read and write events, only 2 of our events require to be persisted. Subsequently, the other 8 read events cannot risk the speed of the queue.

Now a question arises. How to distinguish between these events? Events should be distinguished through the collectors. If a collector does not separate them, then the event queue will be unable to make a decision of its own.

Another approach is to divide an event queue. One event queue will be responsible for dealing solely with the read events while the second one can look after the write events. This saves the resources as no other component in the system has to decide on the persistence of the events. The following example shows the idea behind this approach. Some may feel that it may make the system more complex but in reality, it is reducing the workload of the application.

 

event

 

Final Thoughts

The main benefit of event-based architectures is seen while working with scalable enterprise applications. Event-based architecture also particularly assists in the testing phase and can generate productivity in test driven approaches which means that each core component of an application can be designed and developed separately. Additionally, with low to no coupling, the architecture stands as an excellent choice for the removal of complexity in applications.

by

What Is Cloud Computing? What Are the Challenges Faced by the Cloud?


The word ‘cloud’ has gained significant traction over the past decade. Traditionally, businesses had on-premises architecture. This meant that all the hardware, storage, networking, and other IT assets of an organization were physically located in the organization’s premises. However, this meant that many businesses had to deal with issues related to their IT setups.

For instance, a software development company that worked on the application level was riddled with hacking attempts. As a result, instead of focusing on their core competency, the company had to focus on security solutions. With the advancement of Computer Science and IT technologies, businesses now have the option to outsource their IT requirements to a cloud computing service. So what is cloud computing?

What is Cloud Computing?

Cloud computing refers to the sharing of a wide variety of computing resources that are located remotely. These services are offered by cloud providers. They charge a monthly or yearly fee in exchange for the required services. The word cloud here refers to the Internet through which users can access these services. This means that organizations no longer have to spend a huge sum of money on their IT assets and can focus more on their operations through the enhanced security, speed, mobility, etc.

Cloud Migration Strategies

While moving to the cloud, a number of strategies can ease the transition.

Rehosting

Rehosting means the relocation of a company’s physical servers through IaaS. This means that if a company intends to quickly migrate its systems and architecture, it can do so through rehosting. Hence, it is one of the most common strategies for companies after their management finalizes the decision to adopt the cloud. However, since it is IaaS, the company does not fully delegate its computing needs. As a consequence, OS and application level needs like patching and testing will still be the company’s responsibility.

As an example, consider a Java Spring application which was previously hosted on your Linux environment on a physical server. Now, you can utilize a cloud platform like AWS or Microsoft Azure where you can set up and customize your own Linux and Java environments. The hardware and lower level complexities and abstractions would be handled by the cloud platforms. This will remove the requirement for a physical server for your application. You will only need some modification with the DNS settings, after which your website can become live again.

Replatforming

Replatforming means that an application is upgraded from an onsite software platform to the cloud without any compromise or change in its functionality. This can include moving a RDBMS to the cloud using a database-as-a-service. Similarly, application servers can also be moved to the cloud. This can be extremely helpful in minimizing licenses fees.

For example, consider that you are paying for an application server in Java. If you will ‘re-platform’, then the cloud can run a variety of application servers like the open-source Apache Tomcat which can boost your project.

Adopting re-platforming for your business means a slower migration strategy as compared to rehosting but it offers the best of both worlds as it can strike a fine balance between rehosting and refactoring. As a result, businesses are able to profit through cloud fundamentals and cost optimization, limiting the need for the costs and resources that are needed in the refactoring strategy.

Refactoring

Traditional IT architectures and processes may have been successful earlier but today’s IT world is a different place. The changes and evolutions in development tools and technologies are occurring at a rapid pace. This means that a legacy system that was built with the best tools of its time in early-2000s will not function well with the business requirements of the present-day world.

Replatforming assists companies to reduce their expenditure without modifying their software environments and applications altogether. However, refactoring goes a step ahead. Refactoring deals with the complete transformation of business processes by using cloud-native platforms and features. Thus, the cloud controls the entire software lifecycle including development and deployment of a project.

While refactoring is slower as well as more expensive as compared to other migration strategies, it helps to shift from a monolithic architecture to a serverless one. As a result, the investment can go on to generate greater profits for a business in comparison to a business that still relies on previous IT setups.

Challenges Faced by the Cloud

Despite its benefits, cloud computing faces challenges.

Reluctance

Long before the cloud emerged as a leading technology, businesses relied on traditional IT practices. Many of these businesses were able to maintain their revenues without the need for any major IT adoption. However, with the passage of time, the computing requirements increased with the huge influx of data, and thus the previous strategy of on-premises IT architecture incurred heavy expenses. Therefore, businesses adopted the cloud, which increased their productivity.

However, not all businesses accepted the change. For non-tech savvy management, this meant a giant leap. The decision to completely revolutionize the IT structure of a company is unappealing to many and there are still businesses that are hesitant to adopt the cloud.

Service Quality

When businesses ponder over the decision to move to the cloud, they contact cloud providers for their services. These providers issue a SLA (Service Level Agreement). Some of the questions that businesses need to address in most SLAs are:

  • What are all the cloud services and features that will be provided to the business?
  • What will the provider do in case of an IT failure?
  • Will the business operations run 24/7 even in the case of an IT issue in the provider’s data center?
  • What are the cybersecurity measures for the protection of the company’s data?

Often businesses are not satisfied with the SLAs and consider them to be limited for their business requirements.

Dependability on the Internet

Since cloud services are accessible over the Internet, 24/7 connectivity is vital for smooth operation. This means that as a business goes offline, the Internet-based cloud features and services would be unavailable for the business and its clients. Thus, businesses have to make sure that their cloud provider has backup solutions that can help in the provision of continuous services.

Bandwidth Cost

With the advent of the cloud, businesses no longer have to purchase a server or spend money on the repair of their hardware. However, another cost has emerged. This cost is related to the bandwidth cost. These may be negligible with small applications but when it comes to data-intensive applications, businesses will need to increase their bandwidth expenses.

Final Thoughts

While cloud computing technology deals with a number of technologies, the selection of the appropriate cloud migration strategy can help to minimize the risks explained above and provide a much-needed boost to businesses.

by

Enterprise Architecture as a Service


Enterprise software development is loaded with a plethora of tools where the IT think-tank scratches their heads in order to analyze and pick the right tool that can pass the test of time. In projects where the scope of a domain is not too high, too much planning and analysis are not taken seriously as the code-base can be changed frequently due to the project size. The code is not written in accordance with the best software engineering principles and practices as their optimal benefit cannot be understood in smaller applications.

However, the development of big enterprise project cannot take such liberties where a little mismanagement in the design may result in a catastrophe of greater proportions. It may end in millions for damages. Likewise, the right architecture for an enterprise application carries a greater degree of responsibility. An Enterprise Architecture is a methodological outlook that involves the following:

  • Management of different human and IT assets for maximum output.
  • The type of methods used.
  • System functionalities.

Traditionally, Enterprise Architecture has assisted a leadership in finding loopholes in enterprise domain business processes of IT infrastructure and has proved critical in the expansion of domain business. Hence, EA has been highly significant in the optimization and modernization of business processes. However, times are changing and EA’s shortcomings are becoming more noticeable to the industry experts.

Need for Enterprise as a Service

The major problem with an Enterprise Architecture is its lack of feasibility for SMEs –– domains on a smaller scale find it harder to have dedicated enterprise architect, They prefer architects who are specialized in a domain. Last year a study shed light on EA professionals –– the demand of EA professionals rose by 26 percent. With such demands, the enterprise faces a certain challenge: impracticality of hiring full-time EA professionals. A new model has emerged that addressed such concerns. It is called Enterprise architecture as a Service.

Understanding Enterprise Architecture-as-a-Service

The concept behind EAaaS is not dissimilar to other “as­-a-service” model where a specific set of domain business activities and tasks are given to one centralized group of the Enterprise architect. EAaaS denotes all the planning, analysis, and architectural management to that centralized group. So, how exactly is EAaaS bridging the gap for costs?

Domains do not require assistance for their architectures on a 24/7-basis. Therefore, especially for SMEs, an EA professional may not be of use all the time and they can work on other projects. This is where EAaaS makes the biggest impact. In EAaaS, only the consulting required for any EA consulting or service has to be paid. As a result, domains drive out the same value in minimized costs.

Difference between Enterprise Architecture and Enterprise Architecture as a Service

 

Deliverables

When EA and EAaaS are looked side-by-side, deliverability matters. EAaaS denotes to an approach to streamline all the production processes so a high-quality and fully structured system can be developed. EAaaS does not entail vague promises and definitions where a domain business’ integration with IT tools and systems can be deployed through the practicality of each solution.

Mindset

The general mindset of IT leadership refers to a unique approach where deliverables are taken into account in the post-completion of EA. In Enterprise Architecture as a Service, results are generated and provided with the help of services that remain available in the entire production life cycle. Hence, Enterprise Architecture as a Service incorporates results during its entire process –– as opposed to the Enterprise Architecture strategy in which results are created in the end.

Realistic Expectations

Expectations play a great role in the software lifecycle. When domains use Enterprise Architecture, there is a sense of uncertainty about what exactly can be made and how it can be made. Presentations and visualization of IT goals is another thing, and transforming it into a reality for a practical use case is a far greater challenge. For instance, if an EA is being developed for a specific goal, then the required funds may not be collected, resulting in the loss of confidence for the stakeholders.

The important questions are:

  • How exactly is your EA making a difference?
  • How does it solve a problem in comparison with your rivals?
  • Where do you see your solution after a certain time period like a year?

Today, enterprise architecture is being misused by enterprises where the lack of vision is apparent as the maximum output in each phase is not achieved. Some organizations eye compliance when enablement possesses greater significance. Additionally, modern changes to the systems cannot be carried out.

With the service-based model of EA, the game changes where enablement is prioritized in conjunction with necessary changes.

Advantages of Enterprise as a Service

EAaaS is beneficial due to the following advantages.

Accessibility

The fact that a common party manages the EA brings out a common question, “How are we going to access and communicate with the required services, tools, and architects?” The adoption of an EAaaS does not in any way sacrifice accessibility. EAaaS components provide ease-of-access with user-friendly interfaces — including both the automated and human ones.

Modularity

Modular development is necessary. The benefits of modularity may not be too visible in smaller applications, but they are highly beneficial in enterprise development. EAaaS supports modularity, which means that any domain component or process can be updated or changed without any impact on the rest of the system.

Reusability

Similar to modularity, reusability is a necessary ingredient in any software architecture. Reusability refers to repeating pre-existing IT assets. EAaaS brings reusability to the scene, which can quicken the development lifecycle.

Flexibility

Flexibility refers to the dynamic quality of architectural design. Some situations require heavy changes in the code-base and architectural design where lack of flexibility consumes considerable time.

Portability

Portability relates to the use of architecture’s components to be deployed for other applications. EAaaS helps to port specific modules of a system to a different system, which can increase the pace of deliverables.

Due to the above-mentioned advantages, applications built using EAaaS can be fast-tracked and deployed timely, making it possible to meet all the project deadlines. Likewise, software engineering’s core principles and approaches can be followed in their full spirit and can help in the crafting of high-quality code.