Tag: leadership

Microservice Vs Monolith: The Current State Of Development

Have Things Changed, Where Are We Now

Photo by Tim van der Kuip on Unsplash

There has been an ongoing discussion for years on the best approach to software development. But where do we stand now? Things have rapidly changed and theories have had time to be proven.

What are we talking about?

Microservices and monolithic development. These two different approaches to software architecture that are used to build and deploy applications, have their own unique set of advantages and disadvantages, and the choice between the two often depends on the specific needs and goals of the project.

Microservices

Microservices are a way of building and deploying applications as a set of small, independent services that communicate with each other through APIs. Each service is responsible for a specific aspect of the application, and they can be developed, tested, and deployed independently of each other. This modular approach to development allows for greater flexibility and scalability, as individual services can be easily added, removed, or modified without affecting the rest of the application.

Advantages

  1. Faster development and deployment cycles: Because microservices are small, independent services that can be developed and deployed independently of each other, they allow for faster development and deployment cycles. Developers can work on different parts of the application concurrently, which can lead to quicker release schedules and the ability to deliver new features and updates more frequently.
  2. Greater flexibility and scalability: Microservices are highly flexible and scalable, as each service can be developed, tested, and deployed independently of the rest of the application. This allows for more granular control over resource allocation, and makes it easier to add, remove, or modify individual services as needed.
  3. Easier to debug and troubleshoot: Because each microservice has a narrow focus and is self-contained, it is easier to debug and troubleshoot any issues that may arise. This can save time and resources and improve the overall reliability of the application.
  4. Improved resilience: Microservices are designed to be highly resilient, as each service can operate independently of the others. This can help to reduce the impact of failures or downtime on the overall application, as other services can continue to operate as normal.
  5. Improved team collaboration: Microservices allow for better collaboration between different teams, as each team can focus on a specific aspect of the application. This can improve communication and coordination between teams, and help to ensure that each service is developed to the highest quality.

While these are all great pros, microservices can also be more complex to manage and maintain, as they require more infrastructure and coordination between different teams. They also can be more expensive to develop and operate depending on the skill level and comfort of the team, they can require more resources and infrastructure to support them.

Monoliths

On the other hand, monolithic development involves building a single, large application that includes all of the functionality needed for the application to run. Monolithic applications are typically built and deployed as a single unit, and any changes to the application require a full rebuild and redeployment.

Advantages

  1. Ease of development: A monolithic architecture makes it easier for developers to understand the entire system and make changes to it. This is because all the components of the system are closely integrated and share the same codebase, making it easier to see how changes to one part of the system will affect the rest of the system.
  2. Ease of deployment: Because a monolithic application is a single, self-contained unit, it is relatively straightforward to deploy. This is in contrast to a microservices architecture, where multiple independent services must be deployed and managed separately.
  3. Better performance: A monolithic application can potentially have better performance than a microservices architecture, because it avoids the overhead of making multiple network requests between services.
  4. Easier to scale: Scaling a monolithic application is generally easier than scaling a microservices architecture. This is because all the components of the application are closely integrated, making it easier to add more resources to the entire system as needed.
  5. Better for small teams: A monolithic architecture can be a good choice for small teams or organizations, as it can be easier to manage and maintain than a more complex microservices architecture.

Monolithic applications can be more easier to scale than a microservicce architechture but still difficult to scale and modify overall, as any changes to the application require a full rebuild and redeployment. This can lead to slower development and deployment cycles, as well as longer downtime for the application when updates are being made.

Making A Decision

Ultimately, the choice between microservices and monolithic development depends on the specific needs and goals of the project. For projects that require fast development and deployment cycles, high scalability, and the ability to modify individual parts of the application independently, microservices may be the better choice. On the other hand, for projects that prioritize simplicity and ease of maintenance, monolithic development may be the better option.

When deciding which approach to use, it is important to carefully consider the specific requirements and goals of the project, as well as the resources and infrastructure that are available. By carefully weighing the pros and cons of each approach, it is possible to choose the best architecture for the project and ensure that it meets the needs of the users and stakeholders. So, it is very important to think deeply about the use cases and what you are trying to accomplish before choosing between Microservices and Monolithic development.

Things To Consider

  1. Team size and structure: A microservices architecture may be a good choice for larger teams with well-defined roles and responsibilities, as it allows each team to work independently on their own service. On the other hand, a monolithic architecture may be more suitable for smaller teams, as it allows all team members to work closely together on the same codebase.
  2. Size and complexity of the project: A monolithic architecture may be more suitable for smaller, less complex projects, as it can be easier to develop and maintain. A microservices architecture may be a better choice for larger, more complex projects, as it allows for a more modular, scalable design.
  3. Deployment requirements: The requirements for deploying the application should be taken into consideration when deciding between a microservices or monolithic architecture. A monolithic architecture may be easier to deploy, as it is a single, self-contained unit. A microservices architecture, on the other hand, may be more suitable for applications that need to be deployed in a distributed manner across multiple servers or environments.
  4. Performance and scalability: The performance and scalability needs of the application should be considered when deciding between a microservices or monolithic architecture. A monolithic architecture can potentially have better performance, as it avoids the overhead of making multiple network requests between services. However, a microservices architecture may be more scalable, as it allows for more modular design and easier horizontal scaling.
  5. Future maintenance and evolution: The long-term maintenance and evolution of the application should also be taken into consideration when deciding between a microservices or monolithic architecture. A microservices architecture may be more flexible and easier to maintain in the long term, as it allows for changes to be made to individual services without affecting the rest of the system. A monolithic architecture may be more difficult to modify and evolve over time, as changes to one part of the system can potentially affect the entire system.

There is no one size fits all solution, but with the right questions you can get close.

Microservice Vs Monolith: The Current State Of Development was originally published in A Technologists POV on Medium, where people are continuing the conversation by highlighting and responding to this story.

When Culture Is More Than A Fad

Culture is more than just saying the word “Culture” a lot

If you polled the corporate community about initiatives and goals across 2021–2022 you will probably hear two very common themes, Diversity/Inclusion and Culture. The world has hi-lighted the lack of these in the modern corporate environment. How have corporations responded specifically to culture?

Culture

To help retain talent and unfortunately, sometimes to help employees overlook negative aspects of a company companies employ “Culture”.

When many companies say “culture” what do they mean? I have heard.

We want to be like Google

I’m not really sure what that means, most of the time the person has not worked at Google or event knows anyone there.

We want to build a cool environment where people are free to be themselves, have an open schedule, and really promote the company as a great place

These are some lofty goals, but how to they play out usually? In many cases they are only words. I have seen those goals play out as insane deadlines, worked weekends, additional pressure, planned “culture” activities that get cancelled.

Why?

Because in most cases, “culture” is used as a retention methodology, a means to keep people around. The concern around “culture” should stem from the care and concern of people not the concern for the bottom line. To have a successful “culture” at work people need to be held above the business.

We can illustrate it this way.

A family business is run differently than a non-family business. In a family business you are willing to put up with that 2nd cousin that slacks off or is not great at their job. Why? Because they are family. Instead of a performance review you support that cousin, educate and help them get better. You give them every opportunity to advance.

You care about the person more than the exact job they are doing.

Would a company ever take that approach?

Recently I made a major job change. I never really talked about it here but previously i was the Senior Director of Product Engineering at Comcast, I was responsible for the Strategy and Architecture of their e-commerce platform.

While i was being interviewed for my new role (which i will write more about that interesting process later) i heard something over and over. People are important. Culture is in our blood. I was excited to hear about their return to work policy, that it was geared towards the comfort of their employees. I liked that they covered more modern medical expenses that many companies don’t cover. The list went on and on.

I have to admit, what i heard was great, but i did feel like if i got the job it was only going to hit about 60%-70% of what i was told.

About a month ago I took the position of Senior Director of Software Engineering at Red Ventures and i have to admit i stand corrected. From day one you felt the difference. What made this different?

  • 2 week on boarding — To learn about the company and your environment before you actually start your job.
  • Mental Health Days — The company has given extra fridays off through the year for people to refresh themselves.
  • Openness — Through my first month i met many people at different levels. At the VP level and above i heard people admit to mistakes they made and ask for genuine support.
  • Politeness — It seems funny, but people respect each other so much that you can get into a conversation thread of just thank yous, back and forth.
  • Being Yourself — I listened to one of the best and funniest town hall meetings ever. Each presenter embraced who they are and were not trying to impersonate some corporate persona. Humor was allowed and encouraged.
  • Mental Health — People understood what it was like to learn a new domain, new rules and new people. I was frequently offered the opportunity to take time to refresh and gather myself.
  • Closeness — Within the second week i felt like i had know people for years and I knew that they were willing to support me.

I could go on and on, but i think this illustrates the point. The approach was different from the very beginning. This “Culture” came from the concern from the individual, the real person. Investment in people should be more important than investment in technology or anything else.

How did they drive this? Listen to their C.E.O and Founder.

I can confirm that there are places where people are still important and where you can still be yourself and succeed. Are you looking for that?

Come Join Us, You Won’t Regret It

Come work close to me and my teams

Software Engineer — Dev Tools

Senior Software Engineer, DevTools | Red Ventures

Staff Software Engineer

Staff Software Engineer - Healthline | Red Ventures

When Culture Is More Than A Fad was originally published in A Technologists POV on Medium, where people are continuing the conversation by highlighting and responding to this story.