HOME | Blog | YouTube | LinkedIn | About Me         || Calculators    | SoftEng/Tech Posts    | Code/Scripts

Wednesday, December 20, 2017

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 the initial version of this Python application, I went back into the Cloud9 IDE and changed some code. After doing the “git push” to the master branch, I went back to the AWS CodeStar dashboard and I was able to see in the flow that CodeCommit and CodeDeploy steps automatically started and the code changes were deployed within short time. The URL of the Python web API was provided in the AWS CodeStar dashboard and after browsing to it, or after trying it in Postman, I was able to see my changes.
Try it out because this is how the cloud computing should work; we need to focus on the business logic of our applications and the cloud providers need to take care of the rest. Obviously the AWS CodeStar is the beginning because it is focusing on setting up web applications but the setup of other peripheral services is still not included. For example, if I wanted to set up some SNS topics and SQS queues, I am not sure if the CodeStar would manage that for me.
I am looking forward to future AWS CodeStar enhancements.
Thank you for reading.
Almir Mustafic

Saturday, December 2, 2017

OWNING your sandbox

OWNING your sandbox. As software engineers we all like to work on latest technology and coding new applications. People generally don’t like spending a lot of time maintaining the code. However, in the world of microservices the owners of each microservice are very well known and defined unlike in the world of monolithic applications. That means that you own it in the true sense. You own the code. You own the QA environment. You own the Stage environment. You own the production environment and all the errors that come along with it :) On positive note, you have a lot to be proud of and you can turn it into opportunities :) You own something that is contributing your company’s customers and what you do responsibly affects the lives of many people in a positive way. Almir Mustafic

10,000 foot level view in technology

10,000 foot level view in technology: How useful is it? What can be done at this level? If the 30,000 foot level is the CTO level, then consider the 10,000 foot level as the level that software engineering managers and directors operate at. To achieve the success at 10,000 foot level, you as a software engineering manager need to dive deep into technical details, help the team lay the foundation from BOTH organizational and technical side. It is the little moves that get the team to this level. Once the team’s applications and results at that level, then you as a manager have ability to perform the high level analysis and troubleshooting without necessarily being in code on daily or weekly basis. Therefore, your ability to troubleshoot technical issues at the 10,000 foot level is a testament to the great work of your team. Go TEAM !! Almir Mustafic


AMAZON WORKSPACES. I am not sure how many of you have heard of Amazon WorkSpaces. Let me give you some information and my analysis after using it for some time. What is it? It is the Amazon’s solution to desktops in the cloud. What’s the point? Well, if you want to use a basic less powerful laptop or even use a Chromebook as your daily computer, then you will not be missing the full functionality of a powerful Windows 10 machine. For example, you can use your Chromebook to connect to your Amazon WorkSpace machine and then you get the full Windows 10 experience. The point is that it gives you the experience as if your remote/workspace Windows 10 machine is really part of your Chromebook. Where it makes the most sense is using Chromebooks to connect to your Amazon WorkSpace machine as Chromebooks with Chrome OS are fast for anything you do in the browser and they are very secure; Chromebooks are also generally cheaper than other laptops. Just a thought as an alternative to buying fully functional laptops/PCs/Macs.  Almir Mustafic

Is the grass greener somewhere else?

Is the grass greener somewhere else? I am talking about our jobs. Do you sell your house if the grass in the backyard is not green anymore?  Here are three quotes to think about: “Don’t assume that the grass is greener somewhere else; you should rather attempt watering your own grass first” — somebody “Work to live instead of living to work” — somebody “Love your job and not your company because your employer may one day say goodbye to you” — one of well respected Indian prime ministers The complicated question would be: How do you follow these three quotes and end up enjoying your life and your job? Books have been written about this. I cannot really provide you the answer, but I can definitely tell you the following after being 20 years in software engineering field professionally: If you do it to only satisfy your boss, you are doing it for a wrong reason and that enthusiasm cannot last long and it will NOT turn into positive experience. If you do it for bigger reasons, it will indirectly end up satisfying your boss and others and you will have fun. If things go bad, you have the bigger reasons to be the foundation for future.  You define for yourself what “bigger reasons” means to you. Almir Mustafic

Do-ers in your company should be taking a big role in the process implementation/improvements or at least have an important seat

Do-ers in your company should be taking a big role in the process implementation/improvements or at least have an important seat. Do-ers are connected with reality and they will tell you what works and what does not. When I say “do-ers”, I am talking about people who know what happens on the floor on daily basis. I am talking about creators, innovators, people who grind through technical problems and still speak the business language. I am not saying that do-ers alone have to drive this, but the right thing to do is to first approach them and ask them what they feel the problems are and what they feel the solutions could be. For you to solve problems, you have to have context and to have the right context, you need to be connected with daily activities on the floor. The success of your solutions is directly proportional to your contextual understanding of the problem that you are trying to solve. What worked in another company or what somebody has written in a book cannot necessarily solve your problems. In conclusion, we all need more doing. That's why I am keeping this post short and to the point as there are tasks to be done :) Almir Mustafic

Doing software development from bottom up when you need to or is this a norm?

Doing software development from bottom up when you need to or is this a norm? If somebody asked you to first build the wheels for the car before having the car at all, what would you do? First, I would question if I need to design/build 4 lug or 5 lug wheels. Then I would need to predict or ask about some details to figure out the proper offset and width for the wheels so they don’t stick outside the fenders. Now how does this car analogy apply to software engineering? First, you need to know and define the API contract. Then you would probably build a stub or mocked version of your API and you would put yourself in the shoes of the client trying to use it in cases that you can predict. Depending on the performance requirements, you may end up adding caching and other improvements. This approach is actually not that uncommon. This is actually how you would approach your team to team and microservice to microservice dependencies regardless of how well you know your consumer; it is important to maintain that discipline at the technical level but as for human communication leverage the closeness you have with other teams. Almir Mustafic

X-Factor in Software Engineering

X-factor: If we could put a number on the X-factor that defines success for you as a successful person in your line of work, then we would have a clear mathematical formula for it. X in X-factor is not as simple and quantitative as X in mathematical equations :) Almir Mustafic


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