Call for round the year submissions for Rootconf in 2020

Call for round the year submissions for Rootconf in 2020

Submit a proposal at any time in the year on DevOps, infrastructure security, cloud, and distributed systems. We will find you a suitable opportunity to share your work.

Make a submission

Accepting submissions till 31 Dec 2020, 12:00 PM

About Rootconf:

Rootconf is HasGeek’s annual conference – and now a growing community – around DevOps, systems engineering, DevSecOps, security and cloud. The annual Rootconf conference takes place in May each year, with the exception of 2019 when the conference will be held in June.

Besides the annual conference, we also run meetups, one-off public lectures, debates and open houses on DevOps, systems engineering, distributed systems, legacy infrastructure, and topics related to Rootconf.

This is the place to submit proposals for your work, and get them peer reviewed by practitioners from the community.

Topics for submission:

We seek proposals – for short and long talks, as well as workshops and tutorials – on the following topics:

  1. Case studies of shift from batch processing to stream processing
  2. Real-life examples of service discovery
  3. Case studies on move from monolith to service-oriented architecture
  4. Micro-services
  5. Network security
  6. Monitoring, logging and alerting – running small-scale and large-scale systems
  7. Cloud architecture – implementations and lessons learned
  8. Optimizing infrastructure
  9. SRE
  10. Immutable infrastructure
  11. Aligning people and teams with infrastructure at scale
  12. Security for infrastructure

Contact us:

If you have questions/queries, write to us on rootconf.editorial@hasgeek.com

Hosted by

Rootconf is a forum for discussions about DevOps, infrastructure management, IT operations, systems engineering, SRE and security (from infrastructure defence perspective). more

Manu PK

@manupk

When to stay with modular monoliths over microservices

Submitted Apr 5, 2019

Microservices architecture style has been a prominent talking points over the last few years. Microservices is by no means a silver bullet though, and the design thinking required to create a good microservices architecture is the same as that needed to create a well-structured monolith. This talk briefly covers characteristics of microservices, monoliths and modular monoliths. We will discuss the topics like, does microservices suits all problem domains? Where does it fails? Can we re-look at the existing styles and look for continual improvements in architectural style?

Outline

Microservices architecture style has been a prominent talking points over the last few years. Microservices is by no means a silver bullet though, and the design thinking required to create a good microservices architecture is the same as that needed to create a well-structured monolith. This talk briefly covers characteristics of microservices, monoliths and modular monoliths. We will discuss the topics like, does microservices suits all problem domains? Where does it fails? Can we re-look at the existing styles and look for continual improvements in architectural style?

A modular monolith or a well-thought combination between software components allow fast development while maintaining low complexity. They also allow evolving to a more appropriate architecture when the need appear since logical modules can easily be extracted into physical modules. By (re)visiting various styles, we will look at the guidelines which can be used to choose between a modular monolith and microservices.

The presentation will start with a brief introduction of microservices and its characteristics. We will see the issues with traditional architecture (or the lack of it commonly referred as big ball of mud architecture). We will discuss the possible improvements to monoliths with better modularity. In my experience modular monoliths can solve most problems related to maintainability and architectural stability of systems. You will need microservices when there is a need for variable scaling requirement in the same problem domain or the interacting systems have different contextual domain boundaries. I will try to explain these concepts with practical use cases which I have observed.

Speaker bio

Manu is a top-notch Team Leader and Architect with the passion and experience to build software products which can solve complex business problems. He is an expert full-stack developer, building products from concept to completion, with a proven track record of delivering powerful, stable,clean and comprehensive solutions.

Links

Comments

{{ gettext('Login to leave a comment') }}

{{ gettext('Post a comment…') }}
{{ gettext('New comment') }}
{{ formTitle }}

{{ errorMsg }}

{{ gettext('No comments posted yet') }}

Make a submission

Accepting submissions till 31 Dec 2020, 12:00 PM

Hosted by

Rootconf is a forum for discussions about DevOps, infrastructure management, IT operations, systems engineering, SRE and security (from infrastructure defence perspective). more