SERVICE NAMES, BOUNDARIES (domain lines) and API DEFINITIONS/STANDARDS

SERVICE NAMES, BOUNDARIES (domain lines) and API DEFINITIONS/STANDARDS are some of many important things to achieve the enterprise-level microservice architecture and microservices. Names mean things. So you first need to properly name your services and that’s the names that you would use when talking to your teammates and clients of your services/APIs. I have a separate article on how you go about defining what a microservice is. That's titled "Micro in Microservices" on my site almirsCorner .com. Essentially, you need define the purpose and boundaries of your service. Then you get into API routes and properly defining them for each service. The goal is to keep the routes RESTful and if you run into the situation when they are not, then it should trigger you to revisit the purpose and boundaries of that given microservice. Maybe that service needs to be split into smaller services.

Thank you for reading this.

Almir Mustafic

Comments

Brand New programming language and one solution OR …

Brand New programming language and one solution OR Two existing programming languages, one solution for EACH? I understand that there is no right or wrong. It all depends on your software architecture, team structure, team skills and other factors, but I still want to explain the scenario as it may look familiar to some. Let me explain. Let’s assume that you have microservices and common libraries in two major programming languages. You have some teams who are experts in one and some teams experts in the other programming language. Now you need to come up with a solution for a scenario that all teams will need to leverage. Let’s assume that your cloud platform has an off-the-shelf approach for this but it is supported by a 3rd programming language that your teams do not have much experience in. What is the right thing for your organization and not just from the technical point of view? A) Do you embrace what your cloud platform gives you off the shelf and implement thi...

AWS CodeStar — this is how the cloud computing will work in the future

AWS CodeStar service ?? AWS launched two new important services: * AWS CodeStar * AWS Cloud9 IDE After AWS Re:Invent, I spent some time setting up AWS Cloud9 service. I was a user of Cloud9 before Amazon acquired them. I really like the IDE and I was wondering how it integrates with the rest of the AWS services. Then I did some more learning and setup and here are the results: You can use AWS CodeStar service as an orchestrator/workflow that allows you to: (1) Code an application (different templates with different languages) using AWS Cloud9. (2) Manage the source code via AWS CodeCommit. (3) Deploy it using AWS CodeDeploy. All of this is managed through the AWS CodeStar dashboard. As part of creating a project within AWS CodeStar, I had an option to set it up with just one EC2 or with Elastic Beanstalk. For simplicity I chose the EC2 flavor and successfully deployed the “Hello World” Python Flask application using AWS CodeStar. After I deployed ...

Leaders/Mentors in my life

I have been blessed in my software engineering career with great leaders. Some of them challenged me in technical skills. Some of them challenged me in my organization and leadership skills. Some of them challenged me in both. And all of them made me a better software engineer, a better senior engineer, a better solutions architect, a better teammate, and a better leader. If you are a student, find yourself a mentor. If you are a junior software engineer, find yourself a mentor. If you are an experienced software engineer, find yourself a mentor. Remember, you write your own definition of success and you are your own critic. That may mean that you TRY to perfect every stage of your career, or that may mean that you skip some stages in your career. Remember, you are in control. That’s all I wanted to say today :) Keep geeking out. Almir

Software Engineering Blogger

Search This Blog