As I have written by default Java was a default choice as its my first choice anyways. However I realized that this component could not afford non deterministic nature of garbage collector.

So need was to write program where I could have control over exact memory deallocation without worrying about “stop the world” garbage collection. Natural Choice was C++ but programming is all about having fun and I wanted to try out something new and C++ threading support and syntax is not all that great even in C++11.

So I decided to try out Go. but again Go had an issue of garbage collection and same fear of non determinism creeped in.

So time to try out Rust.

Program is simple but can be extended to lot of other scenarios.

One thread keeps spitting out data at some regular intervals. A vector keeps track of generated data.

Other thread keeps ticking at regular intervals (100ms or so) and whenever there are items which have elapsed time greater than a threshold those items are expired. Same as cache TTL.

use std::thread;
    use std::sync::mpsc;
    use std::time::{Duration,Instant};
    use std::collections::HashMap;
    //Define struct
    #[derive(Clone)]
    struct Item {
        created_at: Instant,
        id:i64,
        pub description: String
    }

//Implement Item
    impl Item {
        pub fn new(id: i64,description: String) -> Item {
            Item {
                created_at: Instant::now(),
                id: id,
                description: description
            }
        }

        fn created_at(&self) -> Instant {
            self.created_at
        }

        fn id(&self) -> i64 {
            self.id
        }
    }

    fn main() {
        let (sender, receiver) = mpsc::channel(); //Creat  multiple publisher single receiver channel
        let sender_pop = sender.clone(); //clone sender
    
        //Create a thread that sends pop every 2 seconds
        thread::spawn(move || {
            //Create infinite loop
            loop {
                thread::sleep(Duration::from_millis(100));
                sender_pop.send(Item::new(-1,String::from("Pop"))).unwrap();
            }
        });

        //Create a thread that keeps sending data every second t
        thread::spawn(move || {
            let mut val = 1;
            //Create infinite loop
            loop {
                val = val + 1;
                sender.send(Item::new(val,String::from("New"))).unwrap();
                thread::sleep(Duration::from_millis(1000));
            }
        });

        //Create a mutable vector
        let mut vals: Vec<Item> = Vec::new(); 
        let ttl = 5; //TTL in seconds
        //Receive items in non blocking fashion
        for received in receiver {
            //let item = &received;
            let mut item = &received;
            let newItem: Item  = item.clone();
            match item.description.as_ref(){
                "Pop" => {
                    println!("Pop");
                    vals.retain(|ref x| Instant::now().duration_since(x.created_at).as_secs() < ttl);
                },
                _ => {
                    vals.push(newItem);
                }
            }
        }
    }

That’s it. You have done synchronisation between threads without any race condition. That’s how cool Rust is.

In the next blog we will try to send notification whenever items are expired.

Happy Coding !!

The post Rust Concurrency first appeared on Ezeiatech.

• Separate lifecycle of each service so services can be deployed independently which means services can evolve separately.
• Each service can be fine tuned for different SLAs and scalability
• Each Service can be developed using different stack
• Each service can be monitored separately

However, Microservice service architecture is not a free lunch. It throws many challenges that must be discussed and dealt with even before venturing into this (unchartered) territory.

• Authorisation – How do you make sure that particular service and its APIs can be called only when user is authorised to do so.
• Data Consistency – ACID is no longer available, deal with eventual consistency.
• Service Discovery – How to find and interact with new services. If there are lots of services then how to make sure that they are discoverable from other services
• Deployment – What if there is a hierarchy in microservice dependency
  • A -> B -> C
• SLA – Multiple hops in a request will add to latency and affect your SLA
• Fault Tolerance – How to handle Cascading Failure
• Monitoring – (How to monitor a system which has 100s or even 1000s of services)
• Tracing  – Logging & Request Tracing (A message will travel across many boundaries so how to nail down where message got lost/delayed)
• Tech Stack – Selecting a stack (to go with single stack or multiple stacks?)
• Packaging and Deploying – (How to come up with a uniform way of packaging and delivering services )
• Debugging – During development phase how to make sure that developers are able to debug code as effectively as they do in monolithic system

The post Microservice Architecture and Its Challenges first appeared on Ezeiatech.

I have worked in various domains writing softwares. All of us know that although developing software for each business domain throws new challenges and their needs differ vastly but there are many tools and systems which are used commonly everywhere.

So, most of the web applications are following this approach what we can call 3-tier applications.

You have got a presentation layer, business layer and a database layer. When you deploy you should be able to deploy on 3 boxes. Surprisingly lot of times you will end up deploying only on 2 boxes. Reason why some company might do this is that they did not segregate between physical and logical layers. One with all the logic and other one with just RDBMS running in background. Even sites like twitter and GroupOn had one big chunk of monolithic softwares where everybody was coding. Later on they decided to dismantle it into smaller blocks as it was impossible to scale this big piece.

Most of seasoned developers understand the meaning of layers but one important thing that they do not understand that a layer can be logical as well as physical.

A logical layer (separation of concerns, modular programming ..whatever you call them) sits in the same process space as other layers and just segregates logic.

You create a layer and expose it’s various functionality via interface. Client of your layer injects them using some fancy library like Guice, Spring or does a “new”.

Many start-up companies at least in India are taking this approach. They start small develop code in one big chunk and when they grow they start dismantling their code into various modules.

It might have worked for some companies but it puts a huge pressure on ROI and dependency increases on the existing developers. If one of them leaves you are doomed. And If I am not wrong you went with no documentation at all by following practices of agile programming (in wrong way). So all you can do is further increase the costs by offering higher wages :-).

On the other hand new people are feeling bad because they are not able to participate much as multiple activities are going on in parallel. Refactoring of current architecture, new feature development, pressure of management to develop new feature and bug fixing/maintenance of existing systems.

For refactoring you have probably cut a new branch and start working there but by the time you are finished your existing branch in production and your re-factored branch have been diverged so much that it becomes another exercise to merge them.

People do it though but almost on daily basis you will get regressions and all this mess will lead to another mess and increase the costs significantly. It will hamper the growth of the company.

There is no one solution to it. Different situations will require different solutions but I have also seen systems which have been managed pretty well over the years and thousands of new developers come and join the new team yet things remain in control.

So how come these two sides of same coin exists. When technology stack is same aren’t we supposed to have same kind of maintainable system?

What different one company did then others. As per me answer lies in Architecture of the systems.

One company was able to get it’s application’s architecture spot on right from the beginning  Another company was doubtful about it’s growth and quickly wanted to put something on dashboard of users and praying that when they grow they will think about it.

This is also not a bad approach it works in many cases but getting the design right in first place does not take so much effort as it looks like.

Web frameworks like Ruby on Rails, Grails and Java script library JQuery are built on the very concept of plugins. It keeps things under control and these small piece of softwares can be maintained easily. If some component starts behaving badly you just stop using it by unloading that particular component.

It is well known practice adopted by experts and computer scientists that one should write code as if he is writing a library. It automatically brings modularity in system and maintenance become very easy (comparatively). and same is true about architecture also. One should develop modules to be consumed by others. Modules or components are supposed to expose a certain functionality. Others are just consuming it.

Great..looks like this is holy grail for solving our problems. Not yet. Once we have created different components and decided to deploy them on different machines we are actually facing host of other issues Deployment, Inter process communication, Fault Tolerance, Centralized logging to name a few.

We will try to solve these problems one by one in upcoming articles.

The post Software Architecture & Its Importance first appeared on Ezeiatech.

Well its not easy. Once you have decided that you want to re-architect the single chunk of software in distributed manner you have to decide about different parts of the system which can be deployed on different machines and still everything will work fine.

There are many problems while doing so.

• How will you host these services (S in SOA).
• How will you communicate and how serialisation/deserialisation will happen?
• How do you make sure that you are able to implement the same workflow which you had in single monolithic component assuming you were doing things sequentially.

To answer the first question there are many options available but I will list down some which I have personal experience with.

1. Design your services as RESTful and deploy them in you preferred container like weblogic.
   • Pros
     • Location transparency. You refer to the services using URI.
     • Interacting with RESTful service is pretty easy in any language.
   • Cons
     • Serious overhead of HTTP protocol.
     • Serious maintenance issues with container management not to mention huge performance hit.
2. Design your services as Java processes and interact with them using a service bus like JMS (ActiveMQ, Fiorano etc.).
3. Design your services as Thrift based and interact with them by passing pre-generated client code.
   • Pros
     • Serialization/Deserialization take care by thrift. You just interact with POJOs everywhere.
     • Lightweight highly scalable proven architecture (Facebook?). Forget about converting from Json to POJO and vice-versa.
   • Cons
     • Every time service or schema is changed you need to redistribute client code.
     • Schema definition in thrift file has some limitations of its own.
4. Design your services as separate Java Processes and have a networking library like ZeroMQ take care of communication.
   • Pros
     • ZeroMQ is battle tested and used in many mission critical projects. Takes care of networking needs.
   • Cons
     • Low level programming is needed compared to other approaches.
     • Many scenarios will have to be handled even with this approach so code size will swell up.

For long time I had been dealign with Hub and Spoke Model by using a ServiceBus like MSMQ, ActiveMQ.

ServiceBus is a popular approach especially in financial institutions who invest in enterprise grade product like TIBCO MQ.

Problem with service bus approach is that you have to write code specific to Messaging Bus. So another layer is added which increases complexity.

So for some time I had been tracking if there is a way to remove this layer. Given my experience in Industry there are some areas I believe a company should not invest until absolutely necessary and one such area is networking.

Having said that one day while learning Scala I came across a project called Akka. Akka is a framework which addresses many problems with simple concept of Actors.

Networking and Concurrency provide easy way to program local or distributed services. What you get is complete location transparency as you communicate with remote actors in same way as you communicate with local actors.

There is no hub and spoke model so no new software has to be installed/maintained or written specific code to make things work.

It’s P2P…networking complexities are hidden deep inside and you never have to deal with thread. WOW !! Sounds too good to be true.

Completely asynchronous with a programming paradigm that is easy to understand and concept of actors is already proven in telecom industry.

In the next post we will talk about some sample code for how location transparency can be achieved.

The post Web Application Scalability – Service Layer first appeared on Ezeiatech.

It surprises me that so many companies still ignore them and produce poor quality code that results in very expensive maintenance over the period and is so fragile that every time you add a new feature immediately bugs creeps in.

I am sharing some of these guidelines which are far from exhaustive but are most important for me. Some things people might not agree with but these are my experiences and many of them are borrowed from classic tests.

GENERAL CODING STANDARDS

These are general predefined standards for developing a code. This reduces

1. Naming Conventions should be descriptive (Variable as well as functions).
2. Your application must have separate static and dynamic parts.
3. No Hard Coding. Find an appropriate place where you can define constants or enums.
4. Prefer simplicity over complexity. If your code is turning out to be very complex most likely you are doing something wrong. As the saying goes its “hard to build simple things”
5. Avoid premature optimization. Define premature optimization for your own use case. Well sounds awkward. Trust me it is. Only experience can tell you what does this really mean
6. Always look for the possibility of following a standard Design Pattern. Tweak it for your own use case
7. Strictly prohibit repetitive code. If the code is repeating it’s a candidate for refactoring.

CLASS DESIGN

1. Class should not be more than 600 lines.
2. Constructor should not have any complex logic and has to be exception safe.
3. Prefer composition over inheritance.
4. Follow one responsibility rule everywhere.
5. Design for extensibility.
6. If in Object Oriented language always define an interface.
7. Avoid circular dependency.

COMMENTS AND ERROR MESSAGES

1. Write comments at all critical places in your code including variable name, their usage, function signature (input/output/parameters).
2. Work with error messages framework. Using error codes for displaying error messages is confusing as it’s hard to figure out which error code is coming from which place. To avoid this chaos, it is recommended to use error message framework.

IF ELSE STATEMENTS

1. Do not write deep nested if else statements.
2. Operator precedence for your language can introduce nasty bugs in your code which are extremely hard to debug. Follow a policy of using parenthesis while writing long if else conditions.

IMPLEMENT OOPS

It is recommended to implement OOPS in your code as much as possible. Program to an interface (contract), not class. Try to make an abstract class for a business service (in case of python/C++, interface in case of Java).

FUNCTIONS

1. Function should not be more than 25 lines.
2. Always check for valid parameters inside public functions. Throw an exception to report an error in params
3. To group the statements logically, try to divide different sections of a function into other smaller functions. E.g. Separate function for initializing values for every possible activity.
4. Use functional programming capabilities if your stack supports it. I.e. pass around functions to write reusable code.
5. Follow Single Responsibility Rule as closely as possible.
6. Functions have to be testable (I should be able to write unit test case for this function). In other words promote loose coupling via Dependency Injection or otherwise.
7. To continue with loose coupling follow the rule “Prefer composition over inheritance”.
8. If you are working with Java8 Never return null. Consider returning Optional
9. Try to avoid multiple return statements. This can put nasty bugs inside programs so it’s best to avoid them as much as possible.
10. Check Big O Complexity of algorithm you are writing. Especially for the case, where you are writing a lot of lines of code or for functions which are on a critical path.

LAYERED ARCHITECTURE

Follow layered architecture in true spirit. Upper Layer should call into lower layers and each layer has to be designed for specific purpose. E.g. while following MVC, Logic in views has to be related to view and all heavy lifting shall be done by the service layer.

PACKAGES

1. All Java Packages should start with com.yourcompany. Check for specific naming convention in your stack but the topmost package has to be your company.
2. Define functions in packages instead of utility. It’s a common malpractice to put every seemingly useful function inside utility classes. And while writing code it becomes difficult to look into these packages. If it’s a business utility function then try to find a proper package for it rather than putting function inside utility classes. Utility classes generally shall have function related to common tasks like String Reverse or some Math functions or may be emailed format checking utility.

LOGGING/TRACING

1. It is recommended to use logging, wherever possible. Purpose of the logging is to diagnose any potential issues in production. Logging is useful but it incurs significant overhead on the application so it must be used wisely and only information required shall be logged.
2. Logging should not be cluttered, it must follow same consistent pattern across the application. Identify a pattern for logging for your specific use case.
3. Logging libraries are incredibly useful. Use their package level capabilities to switch on/off selective logging at different levels.

EXCEPTION HANDLING

1. Do not suppress exceptions.
2. If an exception is explicitly raised in a function then it should not be handled in that same function. Create a separate function to handle exception and process.
3. Do not suppress original exception even if you have to create a new exception.
4. Try to use already available functions in logging libraries.
5. Comment on bypassing function i.e if we are passing any exception then mention in a comment why we are doing this.
6. Try following naming convention for exceptions as per your language e.g. Exception suffix in Java.
7. Do not write complex code in handler. Lot of times this code block throws an exception and hides original exception.
8. Read about exception handling best practices for your respective language and follow same.

The post Code Quality Guidelines first appeared on Ezeiatech.