github.com/tickoalcantara12/micro/v3@v3.0.0-20221007104245-9d75b9bcbab9/docs/blog/_posts/2019-06-10-the-great-consolidation.md (about)

     1  ---
     2  layout:	post
     3  title:	Micro - The great consolidation of 2019
     4  date:	2019-06-10 09:00:00
     5  ---
     6  <br>
     7  Micro started it's journey as [**go-micro**](https://github.com/micro/go-micro) - a microservices framework - focused 
     8  on providing the core requirements for microservice development. It creates a simpler experience for building microservices 
     9  by abstracting away the complexity of distributed systems.
    10  
    11  Over time we've expanded beyond go-micro into additional tools, libraries and plugins. This has led to fragmentation 
    12  in the way we solve problems and how developers are expected to use micro tools. We're now undergoing a consolidation 
    13  of all these tools to simplify the developer experience.
    14  
    15  Micro essentially moves to being a standalone development framework and runtime for microservices development.
    16  
    17  Before we talk about the consolidation, let's revisit the journey thus far.
    18  
    19  ## The Primary Focus
    20  
    21  Go-micro started out as primarily being focused on the communication aspects of microservices and we've tried to remain true to that. 
    22  This opinionated approach and focus is what's really driven the success of the framework thus far. Over the years 
    23  we've had numerous requests to solve the next day problems for building production ready software in go-micro itself. 
    24  Much of this has been related to scalability, security, synchronisation and configuration.
    25  
    26  <center>
    27  <img src="https://m3o.com/docs/images/go-micro.svg" style="width: 80%; height: auto;"/>
    28  </center>
    29  
    30  While there would have been merit to add the additional features requested we really wanted to stay very focused 
    31  on solving one problem really well at first. So we took a different approach to promoting the community to do this.
    32  
    33  ## Ecosystem & Plugins
    34  
    35  Going to production involves much more than vanilla service discovery, message encoding and request-response. 
    36  We really understood this but wanted to enable users to choose the wider platform requirements via pluggable and 
    37  extensible interfaces. Promoting an ecosystem through an [explorer](https://m3o.com/explore/) which aggregates 
    38  micro based open source projects on GitHub along with extensible plugins via the [go-plugins](https://github.com/micro/go-plugins) repo.
    39  
    40  <center>
    41  <img src="https://m3o.com/explorer.png" style="width: 80%; height: auto;" />
    42  </center>
    43  
    44  Go Plugins has generally been a great success by allowing developers to offload significant complexity to systems built 
    45  for those requirements e.g prometheus for metrics, zipkin for distributed tracing and kafka for durable messaging.
    46  
    47  ## Points of Interaction
    48  
    49  Go Micro was really at the heart of microservice development but as services were written the next questions moved on to; 
    50  how do I query these, how do I interact with them, how do I serve them by traditional means...
    51  
    52  Given go-micro used an rpc/protobuf based protocol that was both pluggable and runtime agnostic, we needed some way to address 
    53  this in a way that was true to go-micro itself. This led to the creation of [**micro**](https://github.com/tickoalcantara12/micro), 
    54  the microservice toolkit. Micro provides an api gateway, web dashboard, cli, slack bot, service proxy and much more.
    55  
    56  <center>
    57  <img src="https://m3o.com/assets/images/runtime3.svg" style="width: 80%; height: auto;"/>
    58  </center>
    59  
    60  The micro toolkit acted as interaction points via http api, browser, slack commands and command line interface. These 
    61  are common ways in which we query and build on applications and it was important for us to provide a runtime that 
    62  really enabled this. Yet still it really focused on communication above all else.
    63   
    64  ## Additional Tools
    65  
    66  While the plugins and the toolkit helped users of micro significantly, it still lacked in key areas. It was clear that our community 
    67  wanted us to solve further problems around platform tooling for product development rather than having to do it individually at 
    68  their various companies. We needed the same types of abstractions go-micro provided for things like dynamic configuration, 
    69  distributed synchronization and broader solutions for systems like Kubernetes.
    70  
    71  For these we created:
    72  
    73  - [micro/go-config](https://github.com/micro/go-config) - a dynamic configuration library
    74  - [micro/go-sync](https://github.com/asim/go-sync) - a distributed synchronisation library
    75  - [micro/kubernetes](https://github.com/micro/kubernetes) - micro on kubernetes initialisation
    76  - [examples](https://github.com/micro/examples) - example usage code for micro
    77  - [microhq](https://github.com/microhq) - a place for prebuilt microservices
    78  
    79  These were a few of the repos, libraries and tools used to attempt to solve the wider requirements of our community. Over the 
    80  4 years the number of repos grew and the getting started experience for new users became much more difficult. The barrier to 
    81  entry increased dramatically and with that we knew something needed to change.
    82  
    83  ## Consolidation
    84  
    85  In the past few weeks we've realised [**go-micro**](https://github.com/micro/go-micro) was really the focal point for most of our users 
    86  developing microservices. It's become clear they want additional functionality as part of this library and as a self described 
    87  framework we really need to embrace this by solving those next day concerns without asking a developer to go anywhere else. 
    88  
    89  Essentially **go-micro** will be the all encompassing and standalone framework for microservice development.
    90  
    91  We've started the consolidation process by moving all our libraries into go-micro and we'll continue to refactor over the 
    92  coming weeks to provide a simpler default getting started experience while also adding further features for logging, tracing, metrics, 
    93  authentication, etc.
    94  
    95  <center>
    96  <img src="{{ site.baseurl }}/blog/images/go-micro-repo.png" style="width: 80%; height: auto;" />
    97  </center>
    98  
    99  We're not forgetting about [**micro**](https://github.com/tickoalcantara12/micro) either though. In our minds after you've built your microservices 
   100  there's still a need for a way to query, run and manage them. **Micro** is by all accounts going to be the runtime for micro 
   101  service development. We're working on providing a simpler way to manage the end to end flow of microservice development and 
   102  should have more to announce soon.
   103  
   104  ## Summary
   105  
   106  Micro is the simplest way to build microservices and slowly becoming the defacto standard for Go based microservice development in 
   107  the cloud. We're making that process even simpler by consolidating our efforts into a single development framework and runtime. 
   108  
   109  <center>...</center>
   110  <br>
   111  To learn more check out the [website](https://m3o.com), follow us on [twitter](https://twitter.com/m3ocloud) or 
   112  join the [slack](https://slack.m3o.com) community.
   113  
   114  <h6><a href="https://github.com/tickoalcantara12/micro"><i class="fab fa-github fa-2x"></i> Micro</a></h6>